We don't need `NonNull::as_ptr` debuginfo
In order to stop pessimizing the use of local variables in core, skip debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
Stabilize async closures (RFC 3668)
# Async Closures Stabilization Report
This report proposes the stabilization of `#![feature(async_closure)]` ([RFC 3668](https://rust-lang.github.io/rfcs/3668-async-closures.html)). This is a long-awaited feature that increases the expressiveness of the Rust language and fills a pressing gap in the async ecosystem.
## Stabilization summary
* You can write async closures like `async || {}` which return futures that can borrow from their captures and can be higher-ranked in their argument lifetimes.
* You can express trait bounds for these async closures using the `AsyncFn` family of traits, analogous to the `Fn` family.
```rust
async fn takes_an_async_fn(f: impl AsyncFn(&str)) {
futures::join(f("hello"), f("world")).await;
}
takes_an_async_fn(async |s| { other_fn(s).await }).await;
```
## Motivation
Without this feature, users hit two major obstacles when writing async code that uses closures and `Fn` trait bounds:
- The inability to express higher-ranked async function signatures.
- That closures cannot return futures that borrow from the closure captures.
That is, for the first, we cannot write:
```rust
// We cannot express higher-ranked async function signatures.
async fn f<Fut>(_: impl for<'a> Fn(&'a u8) -> Fut)
where
Fut: Future<Output = ()>,
{ todo!() }
async fn main() {
async fn g(_: &u8) { todo!() }
f(g).await;
//~^ ERROR mismatched types
//~| ERROR one type is more general than the other
}
```
And for the second, we cannot write:
```rust
// Closures cannot return futures that borrow closure captures.
async fn f<Fut: Future<Output = ()>>(_: impl FnMut() -> Fut)
{ todo!() }
async fn main() {
let mut xs = vec![];
f(|| async {
async fn g() -> u8 { todo!() }
xs.push(g().await);
});
//~^ ERROR captured variable cannot escape `FnMut` closure body
}
```
Async closures provide a first-class solution to these problems.
For further background, please refer to the [motivation section](https://rust-lang.github.io/rfcs/3668-async-closures.html#motivation) of the RFC.
## Major design decisions since RFC
The RFC had left open the question of whether we would spell the bounds syntax for async closures...
```rust
// ...as this...
fn f() -> impl AsyncFn() -> u8 { todo!() }
// ...or as this:
fn f() -> impl async Fn() -> u8 { todo!() }
```
We've decided to spell this as `AsyncFn{,Mut,Once}`.
The `Fn` family of traits is special in many ways. We had originally argued that, due to this specialness, that perhaps the `async Fn` syntax could be adopted without having to decide whether a general `async Trait` mechanism would ever be adopted. However, concerns have been raised that we may not want to use `async Fn` syntax unless we would pursue more general trait modifiers. Since there remain substantial open questions on those -- and we don't want to rush any design work there -- it makes sense to ship this needed feature using the `AsyncFn`-style bounds syntax.
Since we would, in no case, be shipping a generalized trait modifier system anytime soon, we'll be continuing to see `AsyncFoo` traits appear across the ecosystem regardless. If we were to ever later ship some general mechanism, we could at that time manage the migration from `AsyncFn` to `async Fn`, just as we'd be enabling and managing the migration of many other traits.
Note that, as specified in RFC 3668, the details of the `AsyncFn*` traits are not exposed and they can only be named via the "parentheses sugar". That is, we can write `T: AsyncFn() -> u8` but not `T: AsyncFn<Output = u8>`.
Unlike the `Fn` traits, we cannot project to the `Output` associated type of the `AsyncFn` traits. That is, while we can write...
```rust
fn f<F: Fn() -> u8>(_: F::Output) {}
```
...we cannot write:
```rust
fn f<F: AsyncFn() -> u8>(_: F::Output) {}
//~^ ERROR
```
The choice of `AsyncFn{,Mut,Once}` bounds syntax obviates, for our purposes here, another question decided after that RFC, which was how to order bound modifiers such as `for<'a> async Fn()`.
Other than answering the open question in the RFC on syntax, nothing has changed about the design of this feature between RFC 3668 and this stabilization.
## What is stabilized
For those interested in the technical details, please see [the dev guide section](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html) I authored.
#### Async closures
Other than in how they solve the problems described above, async closures act similarly to closures that return async blocks, and can have parts of their signatures specified:
```rust
// They can have arguments annotated with types:
let _ = async |_: u8| { todo!() };
// They can have their return types annotated:
let _ = async || -> u8 { todo!() };
// They can be higher-ranked:
let _ = async |_: &str| { todo!() };
// They can capture values by move:
let x = String::from("hello, world");
let _ = async move || do_something(&x).await };
```
When called, they return an anonymous future type corresponding to the (not-yet-executed) body of the closure. These can be awaited like any other future.
What distinguishes async closures is that, unlike closures that return async blocks, the futures returned from the async closure can capture state from the async closure. For example:
```rust
let vec: Vec<String> = vec![];
let closure = async || {
vec.push(ready(String::from("")).await);
};
```
The async closure captures `vec` with some `&'closure mut Vec<String>` which lives until the closure is dropped. Every call to `closure()` returns a future which reborrows that mutable reference `&'call mut Vec<String>` which lives until the future is dropped (e.g. it is `await`ed).
As another example:
```rust
let string: String = "Hello, world".into();
let closure = async move || {
ready(&string).await;
};
```
The closure is marked with `move`, which means it takes ownership of the string by *value*. The future that is returned by calling `closure()` returns a future which borrows a reference `&'call String` which lives until the future is dropped (e.g. it is `await`ed).
#### Async fn trait family
To support the lending capability of async closures, and to provide a first-class way to express higher-ranked async closures, we introduce the `AsyncFn*` family of traits. See the [corresponding section](https://rust-lang.github.io/rfcs/3668-async-closures.html#asyncfn) of the RFC.
We stabilize naming `AsyncFn*` via the "parenthesized sugar" syntax that normal `Fn*` traits can be named. The `AsyncFn*` trait can be used anywhere a `Fn*` trait bound is allowed, such as:
```rust
/// In return-position impl trait:
fn closure() -> impl AsyncFn() { async || {} }
/// In trait bounds:
trait Foo<F>: Sized
where
F: AsyncFn()
{
fn new(f: F) -> Self;
}
/// in GATs:
trait Gat {
type AsyncHasher<T>: AsyncFn(T) -> i32;
}
```
Other than using them in trait bounds, the definitions of these traits are not directly observable, but certain aspects of their behavior can be indirectly observed such as the fact that:
* `AsyncFn::async_call` and `AsyncFnMut::async_call_mut` return a future which is *lending*, and therefore borrows the `&self` lifetime of the callee.
```rust
fn by_ref_call(c: impl AsyncFn()) {
let fut = c();
drop(c);
// ^ Cannot drop `c` since it is borrowed by `fut`.
}
```
* `AsyncFnOnce::async_call_once` returns a future that takes ownership of the callee.
```rust
fn by_ref_call(c: impl AsyncFnOnce()) {
let fut = c();
let _ = c();
// ^ Cannot call `c` since calling it takes ownership the callee.
}
```
* All currently-stable callable types (i.e., closures, function items, function pointers, and `dyn Fn*` trait objects) automatically implement `AsyncFn*() -> T` if they implement `Fn*() -> Fut` for some output type `Fut`, and `Fut` implements `Future<Output = T>`.
* This is to make sure that `AsyncFn*()` trait bounds have maximum compatibility with existing callable types which return futures, such as async function items and closures which return boxed futures.
* For now, this only works currently for *concrete* callable types -- for example, a argument-position impl trait like `impl Fn() -> impl Future<Output = ()>` does not implement `AsyncFn()`, due to the fact that a `AsyncFn`-if-`Fn` blanket impl does not exist in reality. This may be relaxed in the future. Users can work around this by wrapping their type in an async closure and calling it. I expect this to not matter much in practice, as users are encouraged to write `AsyncFn` bounds directly.
```rust
fn is_async_fn(_: impl AsyncFn(&str)) {}
async fn async_fn_item(s: &str) { todo!() }
is_async_fn(s);
// ^^^ This works.
fn generic(f: impl Fn() -> impl Future<Output = ()>) {
is_async_fn(f);
// ^^^ This does not work (yet).
}
```
#### The by-move future
When async closures are called with `AsyncFn`/`AsyncFnMut`, they return a coroutine that borrows from the closure. However, when they are called via `AsyncFnOnce`, we consume that closure, and cannot return a coroutine that borrows from data that is now dropped.
To work around around this limitation, we synthesize a separate future type for calling the async closure via `AsyncFnOnce`.
This future executes identically to the by-ref future returned from calling the async closure, except for the fact that it has a different set of captures, since we must *move* the captures from the parent async into the child future.
#### Interactions between async closures and the `Fn*` family of traits
Async closures always implement `FnOnce`, since they always can be called once. They may also implement `Fn` or `FnMut` if their body is compatible with the calling mode (i.e. if they do not mutate their captures, or they do not capture their captures, respectively) and if the future returned by the async closure is not *lending*.
```rust
let id = String::new();
let mapped: Vec</* impl Future */> =
[/* elements */]
.into_iter()
// `Iterator::map` takes an `impl FnMut`
.map(async |element| {
do_something(&id, element).await;
})
.collect();
```
See [the dev guide](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html#follow-up-when-do-async-closures-implement-the-regular-fn-traits) for a detailed explanation for the situations where this may not be possible due to the lending nature of async closures.
#### Other notable features of async closures shared with synchronous closures
* Async closures are `Copy` and/or `Clone` if their captures are `Copy`/`Clone`.
* Async closures do closure signature inference: If an async closure is passed to a function with a `AsyncFn` or `Fn` trait bound, we can eagerly infer the argument types of the closure. More details are provided in [the dev guide](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html#closure-signature-inference).
#### Lints
This PR also stabilizes the `CLOSURE_RETURNING_ASYNC_BLOCK` lint as an `allow` lint. This lints on "old-style" async closures:
```rust
#![warn(closure_returning_async_block)]
let c = |x: &str| async {};
```
We should encourage users to use `async || {}` where possible. This lint remains `allow` and may be refined in the future because it has a few false positives (namely, see: "Where do we expect rewriting `|| async {}` into `async || {}` to fail?")
An alternative that could be made at the time of stabilization is to put this lint behind another gate, so we can decide to stabilize it later.
## What isn't stabilized (aka, potential future work)
#### `async Fn*()` bound syntax
We decided to stabilize async closures without the `async Fn*()` bound modifier syntax. The general direction of this syntax and how it fits is still being considered by T-lang (e.g. in [RFC 3710](https://github.com/rust-lang/rfcs/pull/3710)).
#### Naming the futures returned by async closures
This stabilization PR does not provide a way of naming the futures returned by calling `AsyncFn*`.
Exposing a stable way to refer to these futures is important for building async-closure-aware combinators, and will be an important future step.
#### Return type notation-style bounds for async closures
The RFC described an RTN-like syntax for putting bounds on the future returned by an async closure:
```rust
async fn foo(x: F) -> Result<()>
where
F: AsyncFn(&str) -> Result<()>,
// The future from calling `F` is `Send` and `'static`.
F(..): Send + 'static,
{}
```
This stabilization PR does not stabilize that syntax yet, which remains unimplemented (though will be soon).
#### `dyn AsyncFn*()`
`AsyncFn*` are not dyn-compatible yet. This will likely be implemented in the future along with the dyn-compatibility of async fn in trait, since the same issue (dealing with the future returned by a call) applies there.
## Tests
Tests exist for this feature in [`tests/ui/async-await/async-closures`](5b54286640/tests/ui/async-await/async-closures).
<details>
<summary>A selected set of tests:</summary>
* Lending behavior of async closures
* `tests/ui/async-await/async-closures/mutate.rs`
* `tests/ui/async-await/async-closures/captures.rs`
* `tests/ui/async-await/async-closures/precise-captures.rs`
* `tests/ui/async-await/async-closures/no-borrow-from-env.rs`
* Async closures may be higher-ranked
* `tests/ui/async-await/async-closures/higher-ranked.rs`
* `tests/ui/async-await/async-closures/higher-ranked-return.rs`
* Async closures may implement `Fn*` traits
* `tests/ui/async-await/async-closures/is-fn.rs`
* `tests/ui/async-await/async-closures/implements-fnmut.rs`
* Async closures may be cloned
* `tests/ui/async-await/async-closures/clone-closure.rs`
* Ownership of the upvars when `AsyncFnOnce` is called
* `tests/ui/async-await/async-closures/drop.rs`
* `tests/ui/async-await/async-closures/move-is-async-fn.rs`
* `tests/ui/async-await/async-closures/force-move-due-to-inferred-kind.rs`
* `tests/ui/async-await/async-closures/force-move-due-to-actually-fnonce.rs`
* Closure signature inference
* `tests/ui/async-await/async-closures/signature-deduction.rs`
* `tests/ui/async-await/async-closures/sig-from-bare-fn.rs`
* `tests/ui/async-await/async-closures/signature-inference-from-two-part-bound.rs`
</details>
## Remaining bugs and open issues
* https://github.com/rust-lang/rust/issues/120694 tracks moving onto more general `LendingFn*` traits. No action needed, since it's not observable.
* https://github.com/rust-lang/rust/issues/124020 - Polymorphization ICE. Polymorphization needs to be heavily reworked. No action needed.
* https://github.com/rust-lang/rust/issues/127227 - Tracking reworking the way that rustdoc re-sugars bounds.
* The part relevant to to `AsyncFn` is fixed by https://github.com/rust-lang/rust/pull/132697.
## Where do we expect rewriting `|| async {}` into `async || {}` to fail?
* Fn pointer coercions
* Currently, it is not possible to coerce an async closure to an fn pointer like regular closures can be. This functionality may be implemented in the future.
```rust
let x: fn() -> _ = async || {};
```
* Argument capture
* Like async functions, async closures always capture their input arguments. This is in contrast to something like `|t: T| async {}`, which doesn't capture `t` unless it is used in the async block. This may affect the `Send`-ness of the future or affect its outlives.
```rust
fn needs_send_future(_: impl Fn(NotSendArg) -> Fut)
where
Fut: Future<Output = ()>,
{}
needs_send_future(async |_| {});
```
## History
#### Important feature history
- https://github.com/rust-lang/rust/pull/51580
- https://github.com/rust-lang/rust/pull/62292
- https://github.com/rust-lang/rust/pull/120361
- https://github.com/rust-lang/rust/pull/120712
- https://github.com/rust-lang/rust/pull/121857
- https://github.com/rust-lang/rust/pull/123660
- https://github.com/rust-lang/rust/pull/125259
- https://github.com/rust-lang/rust/pull/128506
- https://github.com/rust-lang/rust/pull/127482
## Acknowledgements
Thanks to `@oli-obk` for reviewing the bulk of the work for this feature. Thanks to `@nikomatsakis` for his design blog posts which generated interest for this feature, `@traviscross` for feedback and additions to this stabilization report. All errors are my own.
r? `@ghost`
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
Arbitrary self types v2: main compiler changes
This is the main PR in a series of PRs related to Arbitrary Self Types v2, tracked in #44874. Specifically this is step 7 of the plan [described here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688), for [RFC 3519](https://github.com/rust-lang/rfcs/pull/3519).
Overall this PR:
* Switches from the `Deref` trait to the new `Receiver` trait when the unstable `arbitrary_self_types` feature is enabled (the simple bit)
* Introduces new algorithms to spot "shadowing"; that is, the case where a newly-added method in an outer smart pointer might end up overriding a pre-existing method in the pointee (the complex bit). Most of this bit was explored in [this earlier perf-testing PR](https://github.com/rust-lang/rust/pull/127812#issuecomment-2236911900).
* Lots of tests
This should not break compatibility for:
* Stable users, where it should have no effect
* Users of the existing `arbitrary_self_types` feature (because we implement `Receiver` for `T: Deref`) _unless_ those folks have added methods which may shadow methods in inner types, which we no longer want to allow
Subsequent PRs will add better diagnostics.
It's probably easiest to review this commit-by-commit.
r? `@wesleywiser`
Lexing precedes parsing, as you'd expect: `Lexer` creates a
`TokenStream` and `Parser` then parses that `TokenStream`.
But, in a horrendous violation of layering abstractions and common
sense, `Lexer` depends on `Parser`! The `Lexer::unclosed_delim_err`
method does some error recovery that relies on creating a `Parser` to do
some post-processing of the `TokenStream` that the `Lexer` just created.
This commit just removes `unclosed_delim_err`. This change removes
`Lexer`'s dependency on `Parser`, and also means that `lex_token_tree`'s
return value can have a more typical form.
The cost is slightly worse error messages in two obscure cases, as shown
in these tests:
- tests/ui/parser/brace-in-let-chain.rs: there is slightly less
explanation in this case involving an extra `{`.
- tests/ui/parser/diff-markers/unclosed-delims{,-in-macro}.rs: the diff
marker detection is no longer supported (because that detection is
implemented in the parser).
In my opinion this cost is outweighed by the magnitude of the code
cleanup.
Fix our `llvm::Bool` typedef to be signed, to match `LLVMBool`
In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our Rust-side typedef was using `c_uint` instead.
Signed and unsigned integers have the same ABI on most platforms, but that isn't universally true, so we should prefer to be consistent with LLVM.
https://github.com/rust-lang/llvm-project/blob/1268e87/llvm/include/llvm-c/Types.h#L28
ABI checks: add support for loongarch
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
r? `@workingjubilee`
Add unpolished, experimental support for AFIDT (async fn in dyn trait)
This allows us to begin messing around `async fn` in `dyn Trait`. Calling an async fn from a trait object always returns a `dyn* Future<Output = ...>`.
To make it work, Implementations are currently required to return something that can be coerced to a `dyn* Future` (see the example in `tests/ui/async-await/dyn/works.rs`). If it's not the right size, then it'll raise an error at the coercion site (see the example in `tests/ui/async-await/dyn/wrong-size.rs`). Currently the only practical way of doing this is wrapping the body in `Box::pin(async move { .. })`.
This PR does not implement a helper type like a "`Boxing`"[^boxing] adapter, and I'll probably follow-up with another PR to improve the error message for the `PointerLike` trait (something that explains in just normal prose what is happening here, rather than a trait error).
[^boxing]: https://rust-lang.github.io/async-fundamentals-initiative/explainer/user_guide_future.html#the-boxing-adapter
This PR also does not implement new trait solver support for AFIDT; I'll need to think how best to integrate it into candidate assembly, and that's a bit of a matter of taste, but I don't think it will be difficult to do.
This could also be generalized:
* To work on functions that are `-> impl Future` (soon).
* To work on functions that are `-> impl Iterator` and other "dyn rpitit safe" traits. We still need to nail down exactly what is needed for this to be okay (not soon).
Tracking:
* https://github.com/rust-lang/rust/issues/133119
In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our
Rust-side typedef was using `c_uint` instead.
Signed and unsigned integers have the same ABI on most platforms, but that
isn't universally true, so we should prefer to be consistent with LLVM.
allow `symbol_intern_string_literal` lint in test modules
Since #133545, `x check compiler --stage 1` no longer works because compiler test modules trigger `symbol_intern_string_literal` lint errors. Bootstrap shouldn't control when to ignore or enable this lint in the compiler tree (using `Kind != Test` was ineffective for obvious reasons).
Also, conditionally adding this rustflag invalidates the build cache between `x test` and other commands.
This PR removes the `Kind` check from bootstrap and handles it directly in the compiler tree in a more natural way.
suppress field expr with generics error message if it's a method
Don't emit "field expressions may not have generic arguments" if it's a method call without `()`
r? estebank
Fixes#67680
Is this the best way to go? It's by far the simplest I could come up with.
Simplify `rustc_mir_dataflow::abs_domain`.
`rustc_mir_dataflow` has a typedef `AbstractElem` that is equal to `ProjectionElem<AbstractOperand, AbstractType>`. `AbstractOperand` and `AbstractType` are both unit types. There is also has a trait `Lift` to convert a `PlaceElem` to an `AbstractElem`.
But `rustc_mir_middle` already has a typedef `ProjectionKind` that is equal to `ProjectionElem<(), ()>`, which is equivalent to `AbstractElem`. So this commit reuses `ProjectionKind` in `rustc_mir_dataflow`, removes `AbstractElem`, and simplifies the `Lift` trait.
r? ``@pnkfelix``
Some asm! diagnostic adjustments and a papercut fix
Best reviewed commit by commit.
We forgot a `normalize` call in intrinsic checking, causing us to allow literal integers, but not named constants containing that literal. This can in theory affect stable code, but only if libstd contains a stable SIMD type that has an array length that is a named constant. I'd assume we'd have noticed by now due to asm! rejecting those outright.
The error message left me scratching my head for a bit, so I added some extra information to the diagnostic, too.
Pass end position of span through inline ASM cookie
Before this PR, only the start position of the span was passed though the inline ASM cookie to diagnostics. LLVM 19 has full support for 64-bit inline ASM cookies; this PR uses that to pass the end position of the span in the upper 32 bits, meaning inline ASM diagnostics now point at the entire line the error occurred on, not just the first character of it.
codegen `#[naked]` functions using global asm
tracking issue: https://github.com/rust-lang/rust/issues/90957Fixes#124375
This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).
I discussed this approach with `@Amanieu` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.
Combined with https://github.com/rust-lang/rust/pull/127853, if both accepted, I think that resolves all steps from the tracking issue.
r? `@Amanieu`
coverage: Rearrange the code for embedding per-function coverage metadata
This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report.
Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of #133418.
---
There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests.
The first patch is just moving code around, so I suggest looking at the other patches to see the actual changes.
---
try-job: x86_64-gnu
try-job: x86_64-msvc
try-job: aarch64-apple
A previous commit added a search for certain types of "shadowing"
situation where one method (in an outer smart pointer type, typically)
might hide or shadow the method in the pointee.
Performance investigation showed that the naïve approach is too slow -
this commit speeds it up, while being functionally the same.
This still does not actually cause the deshadowing check to emit any
errors; that comes in a subsequent commit which is where all the tests
live.
This is the first part of a series of commits which impact the
"deshadowing detection" in the arbitrary self types v2 RFC.
This commit should not have any functional changes, but may impact
performance. Subsequent commits add back the performance, and add error
checking to this new code such that it has a functional effect.
Rust prioritizes method candidates in this order:
1. By value;
2. By reference;
3. By mutable reference;
4. By const ptr.
5. By reborrowed pin.
Previously, if a suitable candidate was found in one of these earlier
categories, Rust wouldn't even move onto probing the other categories.
As part of the arbitrary self types work, we're going to need to change
that - even if we choose a method from one of the earlier categories, we
will sometimes need to probe later categories to search for methods that
we may be shadowing.
This commit adds those extra searches for shadowing, but it does not yet
produce an error when such shadowing problems are found. That will come
in a subsequent commit, by filling out the 'check_for_shadowing'
method.
This commit contains a naive approach to detecting these shadowing
problems, which shows what we've functionally looking to do. However,
it's too slow. The performance of this approach was explored in this
PR:
https://github.com/rust-lang/rust/pull/127812#issuecomment-2236911900
Subsequent commits will improve the speed of the search.
This commit makes no (intentional) functional change.
Previously, the picking process maintained two lists of extra
information useful for diagnostics:
* any unstable candidates which might have been picked
* any unsatisfied predicates
Previously, these were dealt with quite differently - the former list
was passed around as a function parameter; the latter lived in a RefCell
in the ProbeCtxt.
With this change we increase consistency by keeping them together in a
new PickDiagHints structure, passed as a parameter, with no need for
interior mutability.
The lifecycle of each of these lists remains fairly complex, so it's
explained with new comments in pick_core.
A further cleanup here would be to package the widely-used tuple
(ty::Predicate<'tcx>,
Option<ty::Predicate<'tcx>>,
Option<ObligationCause<'tcx>>)
into a named struct for UnsatisfiedPredicate. This seems worth doing but
it turns out that this tuple is used in dozens of places, so if we're
going to do this we should do it as a separate PR to avoid constant
rebase trouble.
In this new version of Arbitrary Self Types, we no longer use the Deref trait
exclusively when working out which self types are valid. Instead, we follow a
chain of Receiver traits. This enables methods to be called on smart pointer
types which fundamentally cannot support Deref (for instance because they are
wrappers for pointers that don't follow Rust's aliasing rules).
This includes:
* Changes to tests appropriately
* New tests for:
* The basics of the feature
* Ensuring lifetime elision works properly
* Generic Receivers
* A copy of the method subst test enhanced with Receiver
This is really the heart of the 'arbitrary self types v2' feature, and
is the most critical commit in the current PR.
Subsequent commits are focused on:
* Detecting "shadowing" problems, where a smart pointer type can hide
methods in the pointee.
* Diagnostics and cleanup.
Naming: in this commit, the "Autoderef" type is modified so that it no
longer solely focuses on the "Deref" trait, but can now consider the
"Receiver" trait instead. Should it be renamed, to something like
"TraitFollower"? This was considered, but rejected, because
* even in the Receiver case, it still considers built-in derefs
* the name Autoderef is short and snappy.
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose
registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
Rename `projection_def_id` to `item_def_id`
Renames `projection_def_id` to `item_def_id`, since `item_def_id` is what we call the analogous method for ~~`AliasTerm`/`AliasTy`~~ `PolyExistentialProjection`. I keep forgetting that this one is not called `item_def_id`.
Rudimentary heuristic to insert parentheses when needed for RPIT overcaptures lint
We don't have basically any preexisting machinery to detect when parentheses are needed for *types*. AFAICT, all of the diagnostics we have for opaques just... fail when they suggest `+ 'a` when that's ambiguous.
Fixes#132853
[AIX] keep profile-rt symbol alive
Clang passes `-u __llvm_profile_runtime` on AIX. https://reviews.llvm.org/D136192
We want to preserve the symbol in the case there are no instrumented object files.
Validate self in host predicates correctly
`assert_only_contains_predicates_from` was added to make sure that we are computing predicates for the correct self type for a given `PredicateFilter`. That was not implemented correctly for `PredicateFilter::SelfOnly` when there are const predicates.
Fixes#133526
`rustc_mir_dataflow` has a typedef `AbstractElem` that is equal to
`ProjectionElem<AbstractOperand, AbstractType>`. `AbstractOperand` and
`AbstractType` are both unit types. There is also has a trait `Lift` to
convert a `PlaceElem` to an `AbstractElem`.
But `rustc_mir_middle` already has a typedef `ProjectionKind` that is
equal to `ProjectionElem<(), ()>`, which is equivalent to
`AbstractElem`. So this commit reuses `ProjectionKind` in
`rustc_mir_dataflow`, removes `AbstractElem`, and simplifies the `Lift`
trait.
rustc_target: ppc64 target string fixes for LLVM 20
LLVM continues to clean these up, and we continue to make this consistent. This is similar to 9caced7bad, e985396145, and
a10e744faf.
```@rustbot``` label: +llvm-main
Add the `power8-crypto` target feature
Add the `power8-crypto` target feature. This will enable adding some new PPC intrinsics in stdarch (specifically AES, SHA and CLMUL intrinsics). The implied target feature is from [here](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/PowerPC/PPC.td)
```@rustbot``` label A-target-feature O-PowerPC
When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.
When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion.
Fix#97734.
Don't use `AsyncFnOnce::CallOnceFuture` bounds for signature deduction
We shouldn't be using `AsyncFnOnce::CallOnceFuture` projection bounds to deduce anything about the return type of an async closure, **only** `AsyncFnOnce::Output`. This was accidental b/c all we were looking at was the def id of the trait, rather than the projection. This PR fixes that.
This doesn't affect stable code, since `CallOnceFuture` bounds cannot be written on stable.
Fixes#134015
Make `Copy` unsafe to implement for ADTs with `unsafe` fields
As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block.
For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields.
Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`.
This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields.
Tracking: #132922
r? ```@compiler-errors```
[AIX] Pass -bnoipath when adding rust upstream dynamic crates
Unlike ELF linkers, AIX doesn't feature `DT_SONAME` to override
the dependency name when outputing a shared library, which is something
we rely on for dylib crates.
See for reference:
bc145cec45/compiler/rustc_codegen_ssa/src/back/linker.rs (L464))
Thus, `ld` on AIX will use the full path to shared libraries as the dependency if passed it
by default unless `noipath` is passed, so pass it here so we don't end up with full path dependencies
for dylib crates.
LLVM continues to clean these up, and we continue to make this
consistent. This is similar to 9caced7bad,
e985396145, and
a10e744faf.
`@rustbot` label: +llvm-main
Stop pessimizing the use of local variables in core by skipping debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
coverage: Use a query to find counters/expressions that must be zero
As of #133446, this query (`coverage_ids_info`) determines which counter/expression IDs are unused. So with only a little extra work, we can take the code that was using that information to determine which coverage counters/expressions must be zero, and move that inside the query as well.
There should be no change in compiler output.
fix ICE on type error in promoted
Fixes https://github.com/rust-lang/rust/issues/133968
Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
coverage: Prefer to visit nodes whose predecessors have been visited
In coverage instrumentation, we need to traverse the control-flow graph and decide what kind of counter (physical counter or counter-expression) should be used for each node that needs a counter.
The existing traversal order is complex and hard to tweak. This new traversal order tries to be a bit more principled, by always preferring to visit nodes whose predecessors have already been visited, which is a good match for how the counter-creation code ends up dealing with a node's in-edges and out-edges.
For several of the coverage tests, this ends up being a strict improvement in reducing the size of the coverage metadata, and also reducing the number of physical counters needed.
(The new traversal should hopefully also allow some further code simplifications in the future.)
---
This is made possible by the separate simplification pass introduced by #133849. Without that, almost any change to the traversal order ends up increasing the size of the expression table or the number of physical counters.
Lint on combining `#[no_mangle]` and `#[export_name]`
This is my very first contribution to the compiler, even though I read the [chapter about lints](https://rustc-dev-guide.rust-lang.org/diagnostics.html) I'm not very certain that this ~~new lint is done right as a builtin lint~~ PR is right. I appreciate any guidance on how to improve the code.
- Add test for issue #47446
- ~~Implement the new lint `mixed_export_name_and_no_mangle` as a builtin lint (not sure if that is the right way to go)~~ Extend `unused_attributes` lint
- Add suggestion how to fix it
<details>
<summary>Old proposed new lint</summary>
> The `mixed_export_name_and_no_mangle` lint detects usage of both `#[export_name]` and `#[no_mangle]` on the same item which results on `#[no_mangle]` being ignored.
>
> *warn-by-default*
>
> ### Example
>
> ```rust
> #[no_mangle] // ignored
> #[export_name = "foo"] // takes precedences
> pub fn bar() {}
> ```
>
> ### Explanation
>
> The compiler will not respect the `#[no_mangle]` attribute when generating the symbol name for the function, as the `#[export_name]` attribute takes precedence. This can lead to confusion and is unnecessary.
</details>
In most places, the `early` method is listed before the corresponding
`primary` method, like you'd expect. This commit fixes two places where
that isn't the case.
The words "before" and "after" have an obvious temporal meaning, e.g.
`seek_before_primary_effect`,
`visit_statement_{before,after}_primary_effect`. But "before" is also
used to name the effect that occurs before the primary effect of a
statement/terminator; this is `Effect::Before`. This leads to the
confusing possibility of talking about things happening "before/after
the before event".
This commit removes this awkward overloading of "before" by renaming
`Effect::Before` as `Effect::Early`. It also renames some of the
`Analysis` and `ResultsVisitor` methods to be more consistent.
Here are the before and after names:
- `Effect::{Before,Primary}` -> `Effect::{Early,Primary}`
- `apply_before_statement_effect` -> `apply_early_statement_effect`
- `apply_statement_effect` -> `apply_primary_statement_effect`
- `visit_statement_before_primary_effect` -> `visit_after_early_statement_effect`
- `visit_statement_after_primary_effect` -> `visit_after_primary_statement_effect`
(And s/statement/terminator/ for all the terminator events.)
It uses `MaybeInitializedPlaces` and `MaybeUninitializedPlaces`, but
calls the results `live` and `dead`. This is very confusing given that
there are also analyses called `MaybeLiveLocals` and `MaybeStorageLive`
and `MaybeStorageDead`.
This commit changes it to use `maybe_init` and `maybe_uninit`.
Currently they are called (most common) `state`, or `trans`, or (rare)
`on_entry`. I think `trans` is short for "transfer function", which
perhaps made more sense when `GenKillAnalysis` existed. Using `state`
everywhere now is more consistent.
They are only present because it's currently defined in terms of the
domains of `Borrows` and `MaybeUninitializedPlaces` and
`EverInitializedPlaces` via associated types. This commit introduces
typedefs for those domains, avoiding the lifetimes.
Introduce `default_field_values` feature
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.
We now parse const expressions after a `=` in a field definition, to specify a `struct` field default value.
We now allow `Struct { field, .. }` where there's no base after `..`.
`#[derive(Default)]` now uses the default value if present, continuing to use `Default::default()` if not.
```rust
#[derive(Debug)]
pub struct S;
#[derive(Debug, Default)]
pub struct Foo {
pub bar: S = S,
pub baz: i32 = 42 + 3,
}
fn main () {
let x = Foo { .. };
let y = Foo::default();
let z = Foo { baz: 1, .. };
assert_eq!(45, x.baz);
assert_eq!(45, y.baz);
assert_eq!(1, z.baz);
}
```
interpret: clean up deduplicating allocation functions
The "align" and "kind" arguments would be largely ignored in the "dedup" case, so let's move that to entirely separate function.
Let's also remove support for old-style miri_resolve_frame while we are at it. The docs have already said for a while that this must be set to 1.
Add test to check unicode identifier version
This adds a test to verify which version of Unicode is used for identifiers. This is part of the language, documented at https://doc.rust-lang.org/nightly/reference/identifiers.html#r-ident.unicode. The version here often changes implicitly due to dependency updates pulling in new versions, and thus we often don't notice it has changed leaving the documentation out of date. The intent here is to have a canary to give us a notification when it changes so that we can update the documentation.
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.
Support default fields in enum struct variant
Allow default values in an enum struct variant definition:
```rust
pub enum Bar {
Foo {
bar: S = S,
baz: i32 = 42 + 3,
}
}
```
Allow using `..` without a base on an enum struct variant
```rust
Bar::Foo { .. }
```
`#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants.
Support `#[derive(Default)]` on enum struct variants with all defaulted fields
```rust
pub enum Bar {
#[default]
Foo {
bar: S = S,
baz: i32 = 42 + 3,
}
}
```
Check for missing fields in typeck instead of mir_build.
Expand test with `const` param case (needs `generic_const_exprs` enabled).
Properly instantiate MIR const
The following works:
```rust
struct S<A> {
a: Vec<A> = Vec::new(),
}
S::<i32> { .. }
```
Add lint for default fields that will always fail const-eval
We *allow* this to happen for API writers that might want to rely on users'
getting a compile error when using the default field, different to the error
that they would get when the field isn't default. We could change this to
*always* error instead of being a lint, if we wanted.
This will *not* catch errors for partially evaluated consts, like when the
expression relies on a const parameter.
Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`:
- Suggest adding a base expression if there are missing fields.
- Suggest enabling the feature if all the missing fields have optional values.
- Suggest removing `..` if there are no missing fields.
Revert #131669 due to ICEs
Revert [lint: change help for pointers to dyn types in FFI #131669](https://github.com/rust-lang/rust/pull/131669) due to ICE reports:
- <https://github.com/rust-lang/rust/issues/134059> (real-world)
- <https://github.com/rust-lang/rust/issues/134060> (fuzzing)
Closes#134060.
The revert criteria I used to assess whether to post this revert was:
1. It's not trivial to fix-forward. (1) The implementation itself is tricky due to `tcx.is_sized` query not being very trivial. (2) It will need more extensive test coverage for different ty kinds.
2. It is impacting real-world crates, i.e. #134059.
3. `improper_ctypes_definitions` is a warn-by-default lint.
This revert is without prejudice to relanding the changes. The changes can be re-landed with those cases addressed and stronger test coverage.
A rough regression test corresponding to the fuzzed example reported in #134060 is added to check that the revert worked, it is not sufficient for the lint test coverage when the lint improvements are to be relanded. Please feel free to improve the test in the reland.
r? `@workingjubilee` (or compiler)
cc `@niacdoial` (PR author)
The part about zero-sized structures is totally wrong. The rest of
it has almost no explanatory value; there are better explanations in
comments elsewhere.
Introduce `MixedBitSet`
`ChunkedBitSet` is good at avoiding excessive memory usage for programs with very large functgions where dataflow bitsets have very large domain sizes. But it's overly heavyweight for small bitsets, because any non-empty `ChunkedBitSet` takes up at least 256 bytes.
This PR introduces `MixedBitSet`, which is a simple bitset that uses `BitSet` for small/medium bitsets and `ChunkedBitSet` for large bitsets. It's a speed and memory usage win.
r? `@Mark-Simulacrum`
A bunch of cleanups
These are all extracted from a branch I have to get rid of driver queries. Most of the commits are not directly necessary for this, but were found in the process of implementing the removal of driver queries.
Previous PR: https://github.com/rust-lang/rust/pull/132410
A `ChunkedBitSet` has to be at least 2048 bits for it to outperform a
`BitSet`, because that's the chunk size. The largest `SparseBitMatrix`
encountered when compiling the compiler and the entire rustc-perf
benchmark suite is less than 600 bits.
This change is a tiny perf win, but the motivation is more about
avoiding uses of `ChunkedBitSet` outside of `MixedBitSet`.
The test change is necessary to avoid hitting the `<BitSet<T> as
BitRelations<ChunkedBitSet<T>>>::subtract` method that has
`unimplemented!` in its body and isn't otherwise used.
Remove unnecessary `int_type_width_signed` function
This can just use `Ty::int_size_and_signed` instead of making its own version.
You might want to look at this [ignoring whitespace](https://github.com/rust-lang/rust/pull/134020/files?w=1) since a huge bunch of code got un-indented.
Fix: typo in E0751 error explanation
Corrected a grammatical error in the explanation for E0751. Changed "exists" to "exist" to improve clarity and ensure proper grammar in the error message.
Actually walk into lifetimes and attrs in `EarlyContextAndPass`
Visitors that don't also call `walk_*` are kinda a footgun...
I believe all the other early lint functions walk into their types correctly at this point.
Add allocate_bytes and refactor allocate_str in InterpCx for raw byte…
Fixes https://github.com/rust-lang/miri/issues/4025
This PR introduces a new `allocate_bytes` function in InterpCx and refactors `allocate_str` to use it internally. This change improves memory allocation handling in the interpreter by:
1. Adding `allocate_bytes`:
- Direct byte slice allocation support
- Handles both mutable and immutable allocations
- Maintains proper memory alignment and deduplication
2. Refactoring `allocate_str`:
- Now uses `allocate_bytes` internally
- Adds string-specific metadata handling
- Preserves existing string allocation behavior
This is part 1 of the planned changes to improve timezone string handling in Miri. A follow-up PR will update Miri's timezone logic to use this new allocation mechanism.
Related: https://github.com/rust-lang/miri/pull/4069
Add more info on type/trait mismatches for different crate versions
When encountering a type or trait mismatch for two types coming from two different crates with the same name, detect if it is either mixing two types/traits from the same crate on different versions:
```
error[E0308]: mismatched types
--> replaced
|
LL | do_something_type(Type);
| ----------------- ^^^^ expected `dependency::Type`, found `dep_2_reexport::Type`
| |
| arguments to this function are incorrect
|
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
--> replaced
|
LL | pub struct Type(pub i32);
| ^^^^^^^^^^^^^^^ this is the expected type `dependency::Type`
|
::: replaced
|
LL | pub struct Type;
| ^^^^^^^^^^^^^^^ this is the found type `dep_2_reexport::Type`
|
::: replaced
|
LL | extern crate dep_2_reexport;
| ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
| ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
= help: you can use `cargo tree` to explore your dependency tree
note: function defined here
--> replaced
|
LL | pub fn do_something_type(_: Type) {}
| ^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> replaced
|
LL | do_something_trait(Box::new(Type) as Box<dyn Trait2>);
| ------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected trait `dependency::Trait2`, found trait `dep_2_reexport::Trait2`
| |
| arguments to this function are incorrect
|
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
--> replaced
|
LL | pub trait Trait2 {}
| ^^^^^^^^^^^^^^^^ this is the expected trait `dependency::Trait2`
|
::: replaced
|
LL | pub trait Trait2 {}
| ^^^^^^^^^^^^^^^^ this is the found trait `dep_2_reexport::Trait2`
|
::: replaced
|
LL | extern crate dep_2_reexport;
| ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
| ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
= help: you can use `cargo tree` to explore your dependency tree
note: function defined here
--> replaced
|
LL | pub fn do_something_trait(_: Box<dyn Trait2>) {}
| ^^^^^^^^^^^^^^^^^^
```
or if it is different crates that were renamed to the same name:
```
error[E0308]: mismatched types
--> $DIR/type-mismatch-same-crate-name.rs:21:20
|
LL | a::try_foo(foo2);
| ---------- ^^^^ expected `main:🅰️:Foo`, found a different `main:🅰️:Foo`
| |
| arguments to this function are incorrect
|
note: two types coming from two different crates are different types even if they look the same
--> $DIR/auxiliary/crate_a2.rs:1:1
|
LL | pub struct Foo;
| ^^^^^^^^^^^^^^ this is the found type `crate_a2::Foo`
|
::: $DIR/auxiliary/crate_a1.rs:1:1
|
LL | pub struct Foo;
| ^^^^^^^^^^^^^^ this is the expected type `crate_a1::Foo`
|
::: $DIR/type-mismatch-same-crate-name.rs:13:17
|
LL | let foo2 = {extern crate crate_a2 as a; a::Foo};
| --------------------------- one type comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL | extern crate crate_a1 as a;
| --------------------------- one type comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
--> $DIR/auxiliary/crate_a1.rs:10:8
|
LL | pub fn try_foo(x: Foo){}
| ^^^^^^^
error[E0308]: mismatched types
--> $DIR/type-mismatch-same-crate-name.rs:27:20
|
LL | a::try_bar(bar2);
| ---------- ^^^^ expected trait `main:🅰️:Bar`, found a different trait `main:🅰️:Bar`
| |
| arguments to this function are incorrect
|
note: two types coming from two different crates are different types even if they look the same
--> $DIR/auxiliary/crate_a2.rs:3:1
|
LL | pub trait Bar {}
| ^^^^^^^^^^^^^ this is the found trait `crate_a2::Bar`
|
::: $DIR/auxiliary/crate_a1.rs:3:1
|
LL | pub trait Bar {}
| ^^^^^^^^^^^^^ this is the expected trait `crate_a1::Bar`
|
::: $DIR/type-mismatch-same-crate-name.rs:13:17
|
LL | let foo2 = {extern crate crate_a2 as a; a::Foo};
| --------------------------- one trait comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL | extern crate crate_a1 as a;
| --------------------------- one trait comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
--> $DIR/auxiliary/crate_a1.rs:11:8
|
LL | pub fn try_bar(x: Box<Bar>){}
| ^^^^^^^
```
This new output unifies the E0308 errors detail with the pre-existing E0277 errors, and better differentiates the "`extern crate` renamed" and "same crate, different versions" cases.
lint: change help for pointers to dyn types in FFI
### Context
while playing around, I encountered the warning for dyn types in `extern "C"` functions, but even after that I assumed that a (rust) raw pointer could be interpreted in C ('s ABI) as a `void *`... to be fair part of why I ignored the warning is because I wanted to poke at the generated assembly, not make useful code.
### Example
```rust
extern "C"
fn caller(callee: *const dyn Fn(i32)->i32){
// -- snip --
}
```
old warning:
```
warning: `extern` fn uses type `dyn Fn(i32) -> i32`, which is not FFI-safe
--> file/name.rs:42:19
|
42 | fn caller(callee: *const dyn Fn(i32)->i32) {
| ^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
|
= note: trait objects have no C equivalent
= note: `#[warn(improper_ctypes_definitions)]` on by default
```
new warning:
```
warning: `extern` fn uses type `dyn Fn(i32) -> i32`, which is not FFI-safe
--> file/name.rs:42:19
|
42 | fn caller(callee: *const dyn Fn(i32)->i32) -> (){
| ^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
|
= note: this pointer to an unsized type contains metadata, which makes it incompatible with a C pointer
= note: `#[warn(improper_ctypes_definitions)]` on by default
```
This query (`coverage_ids_info`) already determines which counter/expression
IDs are unused, so it only takes a little extra effort to also determine which
counters/expressions must have a value of zero.
On nightly, we mention the trait is unstable
```
error[E0277]: the trait bound `T: Unstable` is not satisfied
--> $DIR/unstable-trait-suggestion.rs:13:9
|
LL | foo(t)
| --- ^ the trait `Unstable` is not implemented for `T`
| |
| required by a bound introduced by this call
|
note: required by a bound in `foo`
--> $DIR/unstable-trait-suggestion.rs:9:11
|
LL | fn foo<T: Unstable>(_: T) {}
| ^^^^^^^^ required by this bound in `foo`
help: consider restricting type parameter `T` but it is an `unstable` trait
|
LL | pub fn demo<T: Unstable>(t: T) {
| ++++++++++
```
On stable, we don't suggest the trait at all
```
error[E0277]: the trait bound `T: Unstable` is not satisfied
--> $DIR/unstable-trait-suggestion.rs:13:9
|
LL | foo(t)
| --- ^ the trait `Unstable` is not implemented for `T`
| |
| required by a bound introduced by this call
|
note: required by a bound in `foo`
--> $DIR/unstable-trait-suggestion.rs:9:11
|
LL | fn foo<T: Unstable>(_: T) {}
| ^^^^^^^^ required by this bound in `foo`
```
As a rule, the application of `unsafe` to a declaration requires that use-sites
of that declaration also require `unsafe`. For example, a field declared
`unsafe` may only be read in the lexical context of an `unsafe` block.
For nearly all safe traits, the safety obligations of fields are explicitly
discharged when they are mentioned in method definitions. For example,
idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields
will require `unsafe` to clone those fields.
Prior to this commit, `Copy` violated this rule. The trait is marked safe, and
although it has no explicit methods, its implementation permits reads of `Self`.
This commit resolves this by making `Copy` conditionally safe to implement. It
remains safe to implement for ADTs without unsafe fields, but unsafe to
implement for ADTs with unsafe fields.
Tracking: #132922
When encountering a type or trait mismatch for two types coming from two different crates with the same name, detect if it is either mixing two types/traits from the same crate on different versions:
```
error[E0308]: mismatched types
--> replaced
|
LL | do_something_type(Type);
| ----------------- ^^^^ expected `dependency::Type`, found `dep_2_reexport::Type`
| |
| arguments to this function are incorrect
|
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
--> replaced
|
LL | pub struct Type(pub i32);
| ^^^^^^^^^^^^^^^ this is the expected type `dependency::Type`
|
::: replaced
|
LL | pub struct Type;
| ^^^^^^^^^^^^^^^ this is the found type `dep_2_reexport::Type`
|
::: replaced
|
LL | extern crate dep_2_reexport;
| ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
| ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
= help: you can use `cargo tree` to explore your dependency tree
note: function defined here
--> replaced
|
LL | pub fn do_something_type(_: Type) {}
| ^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> replaced
|
LL | do_something_trait(Box::new(Type) as Box<dyn Trait2>);
| ------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected trait `dependency::Trait2`, found trait `dep_2_reexport::Trait2`
| |
| arguments to this function are incorrect
|
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
--> replaced
|
LL | pub trait Trait2 {}
| ^^^^^^^^^^^^^^^^ this is the expected trait `dependency::Trait2`
|
::: replaced
|
LL | pub trait Trait2 {}
| ^^^^^^^^^^^^^^^^ this is the found trait `dep_2_reexport::Trait2`
|
::: replaced
|
LL | extern crate dep_2_reexport;
| ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
| ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
= help: you can use `cargo tree` to explore your dependency tree
note: function defined here
--> replaced
|
LL | pub fn do_something_trait(_: Box<dyn Trait2>) {}
| ^^^^^^^^^^^^^^^^^^
```
or if it is different crates that were renamed to the same name:
```
error[E0308]: mismatched types
--> $DIR/type-mismatch-same-crate-name.rs:21:20
|
LL | a::try_foo(foo2);
| ---------- ^^^^ expected `main:🅰️:Foo`, found a different `main:🅰️:Foo`
| |
| arguments to this function are incorrect
|
note: two types coming from two different crates are different types even if they look the same
--> $DIR/auxiliary/crate_a2.rs:1:1
|
LL | pub struct Foo;
| ^^^^^^^^^^^^^^ this is the found type `crate_a2::Foo`
|
::: $DIR/auxiliary/crate_a1.rs:1:1
|
LL | pub struct Foo;
| ^^^^^^^^^^^^^^ this is the expected type `crate_a1::Foo`
|
::: $DIR/type-mismatch-same-crate-name.rs:13:17
|
LL | let foo2 = {extern crate crate_a2 as a; a::Foo};
| --------------------------- one type comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL | extern crate crate_a1 as a;
| --------------------------- one type comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
--> $DIR/auxiliary/crate_a1.rs:10:8
|
LL | pub fn try_foo(x: Foo){}
| ^^^^^^^
error[E0308]: mismatched types
--> $DIR/type-mismatch-same-crate-name.rs:27:20
|
LL | a::try_bar(bar2);
| ---------- ^^^^ expected trait `main:🅰️:Bar`, found a different trait `main:🅰️:Bar`
| |
| arguments to this function are incorrect
|
note: two types coming from two different crates are different types even if they look the same
--> $DIR/auxiliary/crate_a2.rs:3:1
|
LL | pub trait Bar {}
| ^^^^^^^^^^^^^ this is the found trait `crate_a2::Bar`
|
::: $DIR/auxiliary/crate_a1.rs:3:1
|
LL | pub trait Bar {}
| ^^^^^^^^^^^^^ this is the expected trait `crate_a1::Bar`
|
::: $DIR/type-mismatch-same-crate-name.rs:13:17
|
LL | let foo2 = {extern crate crate_a2 as a; a::Foo};
| --------------------------- one trait comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL | extern crate crate_a1 as a;
| --------------------------- one trait comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
--> $DIR/auxiliary/crate_a1.rs:11:8
|
LL | pub fn try_bar(x: Box<Bar>){}
| ^^^^^^^
```
This new output unifies the E0308 errors detail with the pre-existing E0277 errors, and better differentiates the "`extern crate` renamed" and "same crate, different versions" cases.
Remove a lit_to_const call
We have so many special cases of `match expr.kind { Lit() => {}, Unary(Neg, Lit()) => {} }`... I'm trying to figure out how to get these all unified, but outright removing some is good, too. So let's try it.
Tho we don't have many `const {}` blocks in the perf test suite... But I also don't know how common `const { 42 }` blocks are, I'd expect these to occur mostly from macros (like `thread_local!`)
Corrected a grammatical error in the explanation for E0751. Changed "exists" to "exist" to improve clarity and ensure proper grammar in the error message.
Hide errors whose suggestions would contain error constants or types
best reviewed commit-by-commit.
This is work towards cleaning up everything around `lit_to_const` and its mir equivalent.
fixes#123809
Do not implement unsafe auto traits for types with unsafe fields
If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Consequently, auto implementations of unsafe auto traits should not be generated for types with unsafe fields.
Tracking: #132922
r? `@compiler-errors`
It was inconsistently done (sometimes even within a single function) and
most of the rest of the compiler uses fatal errors instead, which need
to be caught using catch_with_exit_code anyway. Using fatal errors
instead of ErrorGuaranteed everywhere in the driver simplifies things a
bit.
Sync cg clif 2024 12 06
The main highlights this time are a Cranelift update disabling the clif ir verifier by default for better performance.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Only allow PassMode::Direct for aggregates on wasm when using the C ABI
For the Rust ABI we don't have any ABI compat reasons to allow PassMode::Direct for aggregates.
Extend Miri to correctly pass mutable pointers through FFI
Based off of https://github.com/rust-lang/rust/pull/129684, this PR further extends Miri to execute native calls that make use of pointers to *mutable* memory.
We adapt Miri's bookkeeping of internal state upon any FFI call that gives external code permission to mutate memory.
Native code may now possibly write and therefore initialize and change the pointer provenance of bytes it has access to: Such memory is assumed to be *initialized* afterwards and bytes are given *arbitrary (wildcard) provenance*. This enables programs that correctly use mutating FFI calls to run Miri without errors, at the cost of possibly missing Undefined Behaviour caused by incorrect usage of mutating FFI.
> <details>
>
> <summary> Simple example </summary>
>
> ```rust
> extern "C" {
> fn init_int(ptr: *mut i32);
> }
>
> fn main() {
> let mut x = std::mem::MaybeUninit::<i32>::uninit();
> let x = unsafe {
> init_int(x.as_mut_ptr());
> x.assume_init()
> };
>
> println!("C initialized my memory to: {x}");
> }
> ```
> ```c
> void init_int(int *ptr) {
> *ptr = 42;
> }
> ```
> should now show `C initialized my memory to: 42`.
>
> </details>
r? ``@RalfJung``
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)
Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.
- Tracking issue: https://github.com/rust-lang/rust/issues/116973
If a type has unsafe fields, its safety invariants are not simply
the conjunction of its field types' safety invariants. Consequently,
it's invalid to reason about the safety properties of these types
in a purely structural manner — i.e., the manner in which `auto`
traits are implemented.
Makes progress towards #132922.
implement checks for tail calls
Quoting the [RFC draft](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md):
> The argument to become is a function (or method) call, that exactly matches the function signature and calling convention of the callee. The intent is to ensure a matching ABI. Note that lifetimes may differ as long as they pass borrow checking, see [below](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md#return-type-coercion) for specifics on the return type.
> Tail calling closures and tail calling from closures is not allowed. This is due to the high implementation effort, see below, this restriction can be lifted by a future RFC.
> Invocations of operators were considered as valid targets but were rejected on grounds of being too error-prone. In any case, these can still be called as methods.
> Tail calling [variadic functions](https://doc.rust-lang.org/beta/unstable-book/language-features/c-variadic.html) and tail calling from variadic functions is not allowed. As support for variadic function is stabilized on a per target level, support for tail-calls regarding variadic functions would need to follow a similar approach. To avoid this complexity and to minimize implementation effort for backends, this interaction is currently not allowed but support can be added with a future RFC.
-----
The checks are implemented as a query, similarly to `check_unsafety`.
The code is cherry-picked straight out of #112657 which was written more than a year ago, so I expect we might need to change some things ^^"
Fix "std" support status of some tier 3 targets
https://github.com/rust-lang/rust/pull/127265 marked targets with empty "std" support status as no-std targets in target-spec metadata:
> * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build
However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.)
https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3
> The `std` column in the table below has the following meanings:
>
> * ✓ indicates the full standard library is available.
> * \* indicates the target only supports [`no_std`] development.
> * ? indicates the standard library support is unknown or a work-in-progress.
>
> [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html
This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata.
The new status is set based on the following criteria:
- Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl)
- Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl f3068b66e0), so I included them in the group below that means “work in progress” rather than in this group.
- Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available.
- Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported.
r? Noratrieb
cc ``@harmou01``
It's a performance win because `MixedBitSet` is faster and uses less
memory than `ChunkedBitSet`.
Also reflow some overlong comment lines in
`lint_tail_expr_drop_order.rs`.
It just uses `BitSet` for small/medium sizes (<= 2048 bits) and
`ChunkedBitSet` for larger sizes. This is good because `ChunkedBitSet`
is slow and memory-hungry at smaller sizes.
Rollup of 10 pull requests
Successful merges:
- #118833 (Add lint against function pointer comparisons)
- #122161 (Fix suggestion when shorthand `self` has erroneous type)
- #133233 (Add context to "const in pattern" errors)
- #133761 (Update books)
- #133843 (Do not emit empty suggestion)
- #133863 (Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro`)
- #133872 (No need to create placeholders for GAT args in confirm_object_candidate)
- #133874 (`fn_sig_for_fn_abi` should return a `ty::FnSig`, no need for a binder)
- #133890 (Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors)
- #133892 (Revert #133817)
r? `@ghost`
`@rustbot` modify labels: rollup
No need to create placeholders for GAT args in confirm_object_candidate
We no longer need this logic to add placeholders for GAT args since with the removal of the `gat_extended` feature gate (https://github.com/rust-lang/rust/pull/133768) we no longer allow GATs in dyn trait anyways.
r? oli-obk
Do not emit empty suggestion
The `println!();` statement's span doesn't include the `;`, and the modified suggestions where trying to get the `;` by getting the differenece between the statement's and the expression's spans, which was an empty suggestion.
Fix#133833, fix#133834.
Add context to "const in pattern" errors
*Each commit addresses specific diagnostics.*
- Add primary span labels
- Point at `const` item, and `const` generic param definition
- Reword messages and notes
- Point at generic param through which an associated `const` is being referenced
- Silence const in pattern with evaluation errors when they come from `const` items that already emit a diagnostic
- On non-structural type in const used as pattern, point at the type that should derive `PartialEq`
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
Make sure to record deps from cached task in new solver on first run
We weren't actually performing a read of the dep node in `with_cached_task` in the new solver, which meant that all queries that computed a goal for the first time were just not recording the query dependencies that we call in that query.
In the incremental test, the typeck query for `fn poll` isn't being marked red even tho it's invalidated due to its writeback results changing. This happens b/c we normalize `Self::Error` into `Error`, which should call `type_of` which is a red query (since `ty::Adt` contains an `AdtDef`, and that `AdtDef`'s stable hash changes since it's ). However, since we weren't tracking deps in that normalize query, the typeck result was remaining green, and we were trying to decode a def id that no longer exists (the field that got removed).
r? lcnr
Point at types that need to be marked with `#[derive(PartialEq)]`.
We use a visitor to look at a type that isn't structural, looking for all ADTs that don't derive `PartialEq`. These can either be manual `impl PartialEq`s or no `impl` at all, so we differentiate between those two cases to provide more context to the user. We also only point at types and impls from the local crate, otherwise show only a note.
```
error: constant of non-structural type `&[B]` in a pattern
--> $DIR/issue-61188-match-slice-forbidden-without-eq.rs:15:9
|
LL | struct B(i32);
| -------- must be annotated with `#[derive(PartialEq)]` to be usable in patterns
LL |
LL | const A: &[B] = &[];
| ------------- constant defined here
...
LL | A => (),
| ^ constant of non-structural type
|
= note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
```
- Point at type that should derive `PartialEq` to be structural.
- Point at manual `impl PartialEq`, explaining that it is not sufficient to be structural.
```
error: constant of non-structural type `MyType` in a pattern
--> $DIR/const-partial_eq-fallback-ice.rs:14:12
|
LL | struct MyType;
| ------------- `MyType` must be annotated with `#[derive(PartialEq)]` to be usable in patterns
...
LL | const CONSTANT: &&MyType = &&MyType;
| ------------------------ constant defined here
...
LL | if let CONSTANT = &&MyType {
| ^^^^^^^^ constant of non-structural type
|
note: the `PartialEq` trait must be derived, manual `impl`s are not sufficient; see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
--> $DIR/const-partial_eq-fallback-ice.rs:5:1
|
LL | impl PartialEq<usize> for MyType {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
```
error: trait object `dyn Send` cannot be used in patterns
--> $DIR/issue-70972-dyn-trait.rs:6:9
|
LL | const F: &'static dyn Send = &7u32;
| -------------------------- constant defined here
...
LL | F => panic!(),
| ^ trait object can't be used in patterns
```
- Add primary span labels.
- Point at const generic parameter used as pattern.
- Point at statics used as pattern.
- Point at let bindings used in const pattern.
Centralize emitting an error in `const_to_pat` so that all errors from that evaluating a `const` in a pattern can add addditional information. With this, now point at the `const` item's definition:
```
error[E0158]: constant pattern depends on a generic parameter
--> $DIR/associated-const-type-parameter-pattern.rs:20:9
|
LL | pub trait Foo {
| -------------
LL | const X: EFoo;
| ------------- constant defined here
...
LL | A::X => println!("A::X"),
| ^^^^
```
The `println!();` statement's span doesn't include the `;`, and the modified suggestions where trying to get the `;` by getting the differenece between the statement's and the expression's spans, which was an empty suggestion.
Fix#133833, fix#133834.
Avoid `opaque type not constrained` errors in the presence of other errors
pulled out of https://github.com/rust-lang/rust/pull/128440
These errors carry no new information if the opaque type was actually used in a constraining (but erroneous) way somewhere.
coverage: Use a separate counter type and simplification step during counter creation
When instrumenting a function's MIR for coverage, there is a point where we need to decide, for each node in the control-flow graph, whether its execution count will be tracked by a physical counter, or by an expression that combines physical counters from other parts of the graph.
Currently the code for doing that is heavily tied to the final form of the LLVM coverage mapping format, and performs some important simplification steps on-the-fly. These factors make the code extremely difficult to modify without breaking or massively worsening the resulting coverage-instrumentation metadata.
---
This PR aims to improve that situation somewhat by adding an extra intermediate representation between the code that chooses how each node will be counted, and the code that converts those decisions into actual tables of physical counters and trees of counter expressions.
As part of doing that, some of the simplifications that are currently performed during the main counter creation step have been pulled out into a separate step.
In most cases the resulting coverage metadata is equivalent, slightly better, or slightly worse. The biggest outlier is `counters.rs`, where the coverage metadata ends up about 10% larger. This seems to be the result of the new approach having less subexpression sharing (because it relies on flatten-sort-cancel), and therefore being less effective at taking advantage of MIR optimizations to replace counters for unused control-flow with zeroes. I think the modest downside is acceptable in light of the future possibilities opened up by this decoupling.
Remove `-Zshow-span`.
It's very old (added in #12087). It's strange, and it's not clear what its use cases are. It only works with the crate root file because it runs before expansion. I suspect it won't be missed.
r? `@estebank`
Don't try and handle unfed `type_of` on anon consts
The `type_of` query for anon consts in the type system is actually implemented by feeding the return value during hir ty lowering, not the hir-based logic in `const_arg_anon_type_of`. The HIR based logic is incomplete (doesn't handle all hir nodes) and also generally wrong to call (re-lowers HIR or invokes typeck which can result in query cycles).
r? `@compiler-errors`
Make CoercePointee errors translatable
Tracked by #123430
Just in case that a translatable error message would become a blocker to stabilization, this PR switches over to fluent error messages, which also slightly improve the wordings and use more accurate span information.
cc `@Darksonn` `@traviscross`
It's very old (added in #12087). It's strange, and it's not clear what
its use cases are. It only works with the crate root file because it
runs before expansion. I suspect it won't be missed.
stop replacing bivariant args with `'static` when computing closure requirements
It is unnecessary, these get constrained when checking that the opaque type is well-formed.
It also results in the opaque type no longer being well formed. If you've got `fn foo<'a>() -> impl Sized + 'a` the opaque is `type Opaque<'a, 'aDummy> where 'a: 'aDummy, 'aDummy: 'a` where `'aDummy` is bivariant. If we call `foo::<'b>()` inside of a closure and its return type ends up in a type test, we start out with the WF `Opaque<'b, 'b>`, and then replace the bivariant `'b` with `'static`. `Opaque<'b, 'static>` is no longer well-formed. Given how these type tests are used, I don't think this caused any practical issues.
r? types
Fix MutVisitor's default implementations to visit Stmt's and BinOp's spans
The `Stmt` case is a bug introduced almost certainly unintentionally by https://github.com/rust-lang/rust/pull/126993. The code _used_ to visit and mutate `span` correctly, but got changed as follows by that PR. Notice how `span` is **copied** into the output by `|kind| Stmt { id, kind, span }` which happens after the mutation in the correct code (red) and before the mutation in the incorrect code (green).
```diff
pub fn noop_flat_map_stmt<T: MutVisitor>(
Stmt { kind, mut span, mut id }: Stmt,
vis: &mut T,
) -> SmallVec<[Stmt; 1]> {
vis.visit_id(&mut id);
- vis.visit_span(&mut span);
let stmts: SmallVec<_> = noop_flat_map_stmt_kind(kind, vis)
.into_iter()
.map(|kind| Stmt { id, kind, span })
.collect();
if stmts.len() > 1 {
panic!(...);
}
+ vis.visit_span(&mut span);
stmts
}
```
[AIX] change AIX default codemodel=large
On AIX, for most libraries, we run out of Table of Contents (TOC) offsets very quickly due to the default 16-bit offset limit. We want the large code model should be used as the default to provide more TOC entries so the end user does not have to specify `-Ccode-model=large` for all their packages. This is even more of an issue with ThinLTO as the ThinLTO globals can very quickly use all available TOC entry.
In addition, on AIX, code with different code-model across different compilation units will not cause undefined behavior, so this is safe to do.
Remove `generic_associated_types_extended` feature gate
This PR retires nightly support for the `generic_associated_types_extended` feature. This feature hasn't received much attention in the last two years or so, and I believe the feature still remains both unsound and ICEy to use. I think that if we were to redesign and reimplement it, we'd want to first figure out how to implement it soundly, but in the mean time I'd prefer to clean this up.
r? ``@lcnr`` cc ``@jackh726`` who added this feature gate I think
improve TagEncoding::Niche docs, sanity check, and UB checks
Turns out the `niche_variants` range can actually contain the `untagged_variant`. We should report this as UB in Miri, so this PR implements that.
Also rename `partially_check_layout` to `layout_sanity_check` for better consistency with how similar functions are called in other parts of the compiler.
Turns out my adjustments to the transmutation logic also fix https://github.com/rust-lang/rust/issues/126267.
Use correct `hir_id` for array const arg infers
Fixes#133771
`self.next_id()` results in the `DefId` for the const argument, created from the hack introduced by #133468, having no `HirId` associated with it. This then results in an ICE in metadata encoding. Fixing this then results in *another* ICE where `encode_defs` was not skipping encoding `type_of` and other queries for `DefId`s when they correspond to a `ConstArgKind::Infer` node.
This only reproduces with a library crate as metadata is not encoded for binaries, and apparently we had 0 tests for `generic_arg_infer` for array lengths in a library crate so this was not caught :<
cc #133589 `@voidc`
r? `@compiler-errors` `@lcnr`
Reduce false positives on some common cases from if-let-rescope lint
r? `@jieyouxu`
We would like to identify a very common case in the ecosystem in which we do not need to apply the lint suggestion for the new Edition 2024 `if let` semantics.
In this patch we excluded linting from `if let`s in statements and block tail expressions. In these simple cases, new Edition 2024 drop orders are identical to those of Edition 2021 and prior.
However, conservatively we should still lint for the other cases, because [this example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2113df5ce78f161d32a1190faf5c7469) shows that the drop order changes are very pronounced, some of which are even sensitive to runtime data.
Gate async fn trait bound modifier on `async_trait_bounds`
This PR moves `async Fn()` trait bounds into a new feature gate: `feature(async_trait_bounds)`. The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier, so we need to gate that separately.
We're trying to work on the general vision of `async` trait bound modifier general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
switch `jemalloc-sys` back to `tikv-jemalloc-sys`, and update to 0.6.0
Some context:
- we used to use jemalloc bindings from https://github.com/gnzlbg/jemallocator, since #55238
- that crate was abandoned, picked up as a fork in https://github.com/tikv/jemallocator, so we switched to that in #83152.
- then they were able to publish to the original `jemalloc-sys` bindings crate, and `jemalloc-sys` and `tikv-jemalloc-sys` became the same thing -- so I switched back to the OG crate in #96790
- they're now having publishing problems again: I've been waiting for https://github.com/tikv/jemallocator/pull/96 for the `jemalloc-sys` 0.6.0 update for a few months, but `tikv-jemalloc-sys` is already updated to 0.6.0.
A perf run showed some improvements, so this PR switches back to `tikv-jemalloc-sys` to update to 0.6.0.
It is unnecessary, these get constrained when checking that the
opaque type is well-formed.
It also results in the opaque type no longer being well formed.
If you've got `fn foo<'a>() -> impl Sized + 'a` the opaque is
`type Opaque<'a, 'aDummy> where 'a: 'aDummy, 'aDummy: 'a` where
`'aDummy` is bivariant. If we call `foo::<'b>()` inside of a closure
and its return type ends up in a type test, we start out with the WF
`Opaque<'b, 'b>`, and then replace the bivariant `'b` with `'static`.
`Opaque<'b, 'static>` is no longer well-formed. Given how these type
tests are used, I don't think this caused any practical issues.
LLVM does not include an implementation of the va_arg instruction for
Xtensa. From what I understand, this is a conscious decision and
instead language frontends are encouraged to implement it themselves.
The rationale seems to be that loading values correctly requires
language and ABI-specific knowledge that LLVM lacks.
This is true of most architectures, and rustc already provides
implementation for a number of them. This commit extends the support to
include Xtensa.
See https://lists.llvm.org/pipermail/llvm-dev/2017-August/116337.html
for some discussion on the topic.
Unfortunately there does not seem to be a reference document for the
semantics of the va_list and va_arg on Xtensa. The most reliable source
is the GCC implementation, which this commit tries to follow. Clang also
provides its own compatible implementation.
This was tested for all the types that rustc allows in variadics.
Co-authored-by: Brian Tarricone <brian@tarricone.org>
Co-authored-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Co-authored-by: Paul Lietar <paul@lietar.net>
Approved in [ACP 491](https://github.com/rust-lang/libs-team/issues/491).
Remove the `unsafe` on `core::intrinsics::breakpoint()`, since it's a
safe intrinsic to call and has no prerequisites.
(Thanks to @zachs18 for figuring out the `bootstrap`/`not(bootstrap)`
logic.)
Deeply normalize when computing implied outlives bounds
r? lcnr
Unfortunately resolving regions is still slightly scuffed (though in an unrelated way). Specifically, we should be normalizing our param-env outlives when constructing the `OutlivesEnv`; otherwise, these assumptions (dd2837ec5d/compiler/rustc_infer/src/infer/outlives/env.rs (L78)) are not constructed correctly.
Let me know if you want us to track that somewhere.
Print name of env var in `--print=deployment-target`
The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.
Behaviour before this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0
```
Behaviour after this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0
```
My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:
- b292ef6934/src/build_context.rs (L1199-L1220)
- daab9244b0/src/lib.rs (L3422-L3426)
`maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](https://github.com/rust-lang/cc-rs/pull/848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](https://github.com/rust-lang/cc-rs/pull/901) [reverted](https://github.com/rust-lang/cc-rs/pull/943) in `v1.0.85`.
So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.
``@BlackHoleFox`` wdyt?
``@rustbot`` label O-apple
r? compiler
Get rid of HIR const checker
As far as I can tell, the HIR const checker was implemented in https://github.com/rust-lang/rust/pull/66170 because we were not able to issue useful const error messages in the MIR const checker.
This seems to have changed in the last 5 years, probably due to work like #90532. I've tweaked the diagnostics slightly and think the error messages have gotten *better* in fact.
Thus I think the HIR const checker has reached the end of its usefulness, and we can retire it.
cc `@RalfJung`
Change `AttrArgs::Eq` to a struct variant
Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808
Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
fix ICE when promoted has layout size overflow
Turns out there is no reason to distinguish `tainted_by_errors` and `can_be_spurious` here, we can just track whether we allow this even in "infallible" constants.
Fixes https://github.com/rust-lang/rust/issues/125476
Use c"lit" for CStrings without unwrap
I've reviewed uses of `CString::new("lit")`.
Some could be changed to `c"lit"`. Some could be changed to `c"lit".to_owned()`, avoiding an `unwrap()`.
Many `CString` documentation examples could be simplified. I deliberately haven't changed all the examples to use the exact same expression, so that they can demonstrate many ways of creating `CString`s.
I've left UI tests mostly unchanged, because `c""` requires edition 2021, but most UI tests use 2015, and I didn't want to accidentally change what the tests are testing.
Move `Const::{from_anon_const,try_from_lit}` to hir_ty_lowering
Fixes#128176.
This accomplishes one of the followup items from #131081.
These operations are much more about lowering the HIR than about
`Const`s themselves. They fit better in hir_ty_lowering with
`lower_const_arg` (formerly `Const::from_const_arg`) and the rest.
To accomplish this, `const_evaluatable_predicates_of` had to be changed
to not use `from_anon_const` anymore. Instead of visiting the HIR and
lowering anon consts on the fly, it now visits the `rustc_middle::ty`
data structures instead and directly looks for `UnevaluatedConst`s. This
approach was proposed in:
https://github.com/rust-lang/rust/pull/131081#discussion_r1821189257
r? `@BoxyUwU`
show forbidden_lint_groups in future-compat reports
Part of https://github.com/rust-lang/rust/issues/81670. This has been a future-compat lint for a while, time to dial it up to show up in reports.
These operations are much more about lowering the HIR than about
`Const`s themselves. They fit better in hir_ty_lowering with
`lower_const_arg` (formerly `Const::from_const_arg`) and the rest.
To accomplish this, `const_evaluatable_predicates_of` had to be changed
to not use `from_anon_const` anymore. Instead of visiting the HIR and
lowering anon consts on the fly, it now visits the `rustc_middle::ty`
data structures instead and directly looks for `UnevaluatedConst`s. This
approach was proposed in:
https://github.com/rust-lang/rust/pull/131081#discussion_r1821189257
`impl Default for EarlyDiagCtxt`
for small rustc_driver programs, most of their imports will currently be related to diagnostics. this change simplifies their code so it's more clear what in the driver is modified from the default.
this is especially important for external drivers which are out of tree and not updated in response to breaking changes. for these drivers, each import is a liability for future code, since it can be broken when refactors happen.
here is an example driver which is simplified by these changes:
```diff
diff --git a/src/main.rs b/src/main.rs
index f81aa3e..11e5f18 100644
--- a/src/main.rs
+++ b/src/main.rs
`@@` -1,16 +1,8 `@@`
#![feature(rustc_private)]
extern crate rustc_driver;
extern crate rustc_interface;
-extern crate rustc_errors;
-extern crate rustc_session;
use rustc_driver::Callbacks;
-use rustc_errors::{emitter::HumanReadableErrorType, ColorConfig};
use rustc_interface::interface;
-use rustc_session::config::ErrorOutputType;
-use rustc_session::EarlyDiagCtxt;
struct DisableSafetyChecks;
`@@` -26,11 +18,7 `@@` fn main() {
"https://github.com/jyn514/jyn514.github.io/issues/new",
|_| (),
);
- let handler = EarlyDiagCtxt::new(ErrorOutputType::HumanReadable(
- HumanReadableErrorType::Default,
- ColorConfig::Auto,
- ));
- rustc_driver::init_rustc_env_logger(&handler);
+ rustc_driver::init_rustc_env_logger(&Default::default());
std::process::exit(rustc_driver::catch_with_exit_code(move || {
let args: Vec<String> = std::env::args().collect();
rustc_driver::RunCompiler::new(&args, &mut DisableSafetyChecks).run()
```
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
check local cache even if global is usable
we store overflow errors locally, even if we can otherwise use the global cache for this goal. should fix#133616, didn't test it locally yet as diesel tends to hit an unrelated debug assertion in rustdoc.
r? types
for small rustc_driver programs, most of their imports will currently be related to diagnostics. this change simplifiers their code so it's more clear what in the driver is modified from the default.
this is especially important for external drivers which are out of tree and not updated in response to breaking changes. for these drivers, each import is a liability for future code, since it can be broken when refactors happen.
here is an example driver which is simplified by these changes:
```
diff --git a/src/main.rs b/src/main.rs
index f81aa3e..11e5f18 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -1,16 +1,8 @@
#![feature(rustc_private)]
extern crate rustc_driver;
extern crate rustc_interface;
-extern crate rustc_errors;
-extern crate rustc_session;
use rustc_driver::Callbacks;
-use rustc_errors::{emitter::HumanReadableErrorType, ColorConfig};
use rustc_interface::interface;
-use rustc_session::config::ErrorOutputType;
-use rustc_session::EarlyDiagCtxt;
struct DisableSafetyChecks;
@@ -26,11 +18,7 @@ fn main() {
"https://github.com/jyn514/jyn514.github.io/issues/new",
|_| (),
);
- let handler = EarlyDiagCtxt::new(ErrorOutputType::HumanReadable(
- HumanReadableErrorType::Default,
- ColorConfig::Auto,
- ));
- rustc_driver::init_rustc_env_logger(&handler);
+ rustc_driver::init_rustc_env_logger(&Default::default());
std::process::exit(rustc_driver::catch_with_exit_code(move || {
let args: Vec<String> = std::env::args().collect();
rustc_driver::RunCompiler::new(&args, &mut DisableSafetyChecks).run()
```
The `Borrowed` variant is no longer used. This commit removes it, along
with the `as_results_cursor` method that produces it, and renames
`as_results_cursor_mut` as `as_results_cursor`.
As of #133155 `Formatter:new` uses `as_results_cursor` to create a
non-mutable results reference, and then later that is accessed via
`deref_mut` which results in a runtime abort. Changing to
`as_results_cursor_mut` fixes it.
Fixes#133641.
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
coverage: Use a query to identify which counter/expression IDs are used
Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen.
This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function.
---
There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
Only error raw lifetime followed by `\'` in edition 2021+
Fixes#133479
cc #132341
I think this fixes a purely theoretical regression since it only affects edition 2015 (who is using that?) and only in the very rare case of a raw lifetime followed immediately by a lifetime like `'r#a'r`.
Make `adjust_fulfillment_errors` work with `HostEffectPredicate` and `const_conditions`
Greatly improves the spans for reporting unsatisfied `~const` bounds :)
r? project-const-traits or maybe ``@lcnr`` (if you want to deal with a diagnostics PR lmao)
Properly pass linker arguments that contain commas
When linking with the system C compiler, we sometimes want to forward certain arguments unchanged to the linker. This can be done with `-Wl,arg1,arg2` or `-Xlinker arg1 -Xlinker arg2`. `-Wl` is used when possible, since it is more compact, but it does not support commas in the argument itself - in those cases, we need to use `-Xlinker`, and that is what this PR implements.
This also fixes using sanitizers on macOS with `-Clinker-flavor=ld`, as those were previously manually using `-Wl`/`-Xlinker` (probably since the support wasn't present in the `link_args` function).
Note that there has been [a previous PR for this](https://github.com/rust-lang/rust/pull/38798), but it only implemented this in certain cases when passing `-rpath`.
r? compiler
Rollup of 8 pull requests
Successful merges:
- #128184 (std: refactor `pthread`-based synchronization)
- #132047 (Robustify and genericize return-type-notation resolution in `resolve_bound_vars`)
- #133515 (fix: hurd build, stat64.st_fsid was renamed to st_dev)
- #133602 (fix: fix codeblocks in `PathBuf` example)
- #133622 (update link to "C++ Exceptions under the hood" blog)
- #133660 (Do not create trait object type if missing associated types)
- #133686 (Add diagnostic item for `std::ops::ControlFlow`)
- #133689 (Fixed typos by changing `happend` to `happened`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add diagnostic item for `std::ops::ControlFlow`
This will be used in Clippy to detect useless conversions done through `ControlFlow::map_break()` and `ControlFlow::map_continue()`.
Robustify and genericize return-type-notation resolution in `resolve_bound_vars`
#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)).
However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect.
This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds.
Tracking:
- https://github.com/rust-lang/rust/issues/109417
Respect verify-llvm-ir option in the backend
We are currently unconditionally verifying the LLVM IR in the backend (twice), ignoring the value of the verify-llvm-ir option. This has substantial compile-time impact for debug builds.
Make `compare_impl_item` into a query
Turns `compare_impl_item` into a query (generalizing the existing query for `compare_impl_const`), and uses that in `Instance::resolve` to fail resolution when an implementation is incompatible with the trait it comes from.
Fixes#119701Fixes#121127Fixes#121411Fixes#129075Fixes#129127Fixes#129214Fixes#131294
Eliminate print_expr_maybe_paren function from pretty printers
This PR is part of backporting Syn's expression precedence design into rustc. (See #133603 for other work on this.)
In Syn, our version of `print_expr_cond_paren` is called `print_subexpression` and it is called from 19 places. Of those calls, 12 of them need a "custom" behavior for the `needs_paren` argument, whereas only 7 use a "standard" behavior resembling `print_subexpression($e, $e.precedence() < Precedence::$Variant, ...)`. In other words the behavior that rustc_ast_pretty's `print_expr_maybe_paren` implements is actually not what you want most of the time. The current usage you see in rustc is overuse.
<details>
<summary>Aside: am I confident about the correctness of Syn's parenthesization? Yes. Click for details.</summary>
---
The behavior is constrained by the following pair of tests which both run over every Rust source file of rustc and the standard library and tools and test suites:
- To rule out **false positives**: for every expression in every source file, print the expression, parse it back, and verify that not a single new parenthesis got added. Since these are expressions parsed from source code, not macro-generated syntax trees, we know they must never need automatic parenthesis insertion. Rustc's pretty printer does not pass this.
Pseudocode: `assert(expr == parse(print(expr)))`
- To rule out **false negatives**: for every expression in every source file, replace every Expr::Paren node in the syntax tree with just its contents, i.e. stripping the parentheses but otherwise preserving the syntax tree structure. Then print the stripped expression performing parenthesis insertion wherever needed, and reparse it. Verify that the reparsed expression has identical structure to the original, despite there being no parentheses in the original prior to printing, i.e. all the right parentheses got re-inserted by the printer to preserve the expression's structure. Rustc's pretty printer does not pass this. See https://github.com/dtolnay/syn/pull/1788 which reveals multiple rustc_ast_pretty bugs.
Pseudocode: `assert(unparenthesize(expr) == unparenthesize(parse(print(unparenthesize(expr)))))`
---
</details>
If `print_expr_maybe_paren` is usually not correct, is there harm in keeping it for the minority of cases where it is correct? I think the answer is yes and Syn doesn't use any equivalent of this helper function. The problems with it are:
- Having both `print_expr_maybe_paren` and `print_expr_cond_paren` applies counterproductive inertia against moving from the first to the second. When looking at a call site like `print_expr_maybe_paren(e, Precedence::$Variant, ...)` with parentheses not being inserted where they should be, anyone's first inclination would be to solve the bug by tweaking $Variant because that is the only knob that visibly appears in the function call. For example to pass "prec + 1", like tweaking the code to conditionally pass `Precedence::Prefix` instead of `Precedence::Cast`.
Experience in Syn shows this is (almost?) never what you want the person to do. In a call `print_expr_cond_paren(e, e.precedence() < ExprPrecedence::$Variant, ...)` almost always the best fix involves one of:
- Changing `e.precedence()`, e.g. to `fixup.leading_precedence(e)` and `fixup.trailing_precedence(e)` in cases of asymmetrical precedence (`(return 1) + 1` vs `1 + return 1`).
- Changing `<` to `<=`, to handle associativity and other grammar restrictions like chained comparisons (which rustc gets wrong today).
- Adding `||` and/or `&&` clauses to the condition.
By using these 3 better knobs instead of $Variant, it upholds the property that any time we talk about precedence, it is always the precedence of some actual expression that our code is actively manipulating, instead of a value standing in for some imaginary precedence level that would exist between two consecutive [real levels](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). For example consider that "`Cast` + 1" might be `Prefix` today, but only until some new Rust syntax ends up adding a level between those.
- The `print_expr_maybe_paren` call sites look shorter, but they are not clearer. For myself, a function argument that says "does this subexpression need parenthesization" is a concrete thing that is easy to think about, while a function argument that is "what is the effective precedence level associated with this subexpression's placement inside its parent expression" is abstract and tricky to even state a precise meaning for. I expect that for someone less familiar with the pretty printer working on adding a new expression kind (like postfix match, recently), having every subexpression consistently printed using `print_expr_cond_paren` will be more beneficial, for the same reason, than having `print_expr_maybe_paren` available.
r? ``@lcnr``
Mark visionOS as supporting `std`
Cargo's -Zbuild-std has recently started checking this field, which causes it to fail to compile even though we have full support for the standard library on these targets.
[Example of failed build](https://github.com/rust-random/getrandom/actions/runs/12069033154/job/33655430622).
Affected targets: `aarch64-apple-visionos` and `aarch64-apple-visionos-sim`.
r? Noratrieb (because you've worked with `rustc` target metadata IIRC)
``@rustbot`` label O-visionos
use stores of the correct size to set discriminants
Resolves an old HACK /FIXME.
Note that I haven't worked much with codegen so I'm not sure if I'm using the functions correctly and I was surprised seeing out-of-range values being fed into `const_uint_big` but apparently they're wrapped implicitly? By making it explicit we can pass in-range values instead.
Support input/output in vector registers of PowerPC inline assembly
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types as input/output.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| PowerPC | `vreg` | `altivec` | `i8x16`, `i16x8`, `i32x4`, `f32x4` |
| PowerPC | `vreg` | `vsx` | `f32`, `f64`, `i64x2`, `f64x2` |
In addition to floats and `core::simd` types listed above, `core::arch` types and custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types and relevant target features are currently unstable.
r? `@Amanieu`
`@rustbot` label +O-PowerPC +A-inline-assembly
Improve span handling in `parse_expr_bottom`.
`parse_expr_bottom` stores `this.token.span` in `lo`, but then fails to use it in many places where it could. This commit fixes that, and likewise (to a smaller extent) in `parse_ty_common`.
r? ``@spastorino``
Simplify hir_typeck_pass_to_variadic_function
r? ``@compiler-errors``
This reworks a bit how the diagnostic is generated so that it does the same as #133538
The `help` is useless now so I removed it
Add `+forced-atomics` feature to esp32s2 no_std target
Similar to https://github.com/rust-lang/rust/pull/114499 but for the Xtensa backend. The ESP32-S2 doesn't have native atomic support, but can have atomic load/stores as part of the ISA with this LLVM codegen feature.
Note: The current rev of LLVM that rustc is using doesn't contain the `+forced-atomics` feature for Xtensa, but I'm pushing this now to remove the patch from our fork in `esp-rs/rust`.
r? ``@Amanieu`` because you reviewed the related RISC-V PR
Fix target_feature handling in freg of LoongArch inline assembly
In LoongArch inline assembly, freg currently always accepts f32/f64 as input/output.
9b4d7c6a40/compiler/rustc_target/src/asm/loongarch.rs (L41)
However, these types actually require f/d target features as in RISC-V.
Otherwise, an (ugly) compile error will occur: https://godbolt.org/z/K61Gq1E9E
f32/f64 without f:
```
error: couldn't allocate output register for constraint '{$f1}'
--> <source>:12:11
|
12 | asm!("", in("$f1") x, lateout("$f1") y);
| ^
```
f64 with f but without d:
```
error: scalar-to-vector conversion failed, possible invalid constraint for vector type
--> <source>:19:11
|
19 | asm!("", in("$f1") x, lateout("$f1") y);
| ^
```
cc ``@heiher``
r? ``@Amanieu``
``@rustbot`` label +O-LoongArch +A-inline-assembly
Do not call `extern_crate` on current trait on crate mismatch errors
When we encounter an error caused by traits/types of different versions of the same crate, filter out the current crate when collecting spans to add to the context so we don't call `extern_crate` on the `DefId` of the current crate, which is meaningless and ICEs.
Produced output with this filter:
```
error[E0277]: the trait bound `foo::Struct: Trait` is not satisfied
--> y.rs:13:19
|
13 | check_trait::<foo::Struct>();
| ^^^^^^^^^^^ the trait `Trait` is not implemented for `foo::Struct`
|
note: there are multiple different versions of crate `foo` in the dependency graph
--> y.rs:7:1
|
4 | extern crate foo;
| ----------------- one version of crate `foo` is used here, as a direct dependency of the current crate
5 |
6 | pub struct Struct;
| ----------------- this type implements the required trait
7 | pub trait Trait {}
| ^^^^^^^^^^^^^^^ this is the required trait
|
::: x.rs:4:1
|
4 | pub struct Struct;
| ----------------- this type doesn't implement the required trait
5 | pub trait Trait {}
| --------------- this is the found trait
= note: two types coming from two different versions of the same crate are different types even if they look the same
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `check_trait`
--> y.rs:10:19
|
10 | fn check_trait<T: Trait>() {}
| ^^^^^ required by this bound in `check_trait`
```
Fix#133563.
[AIX] handle libunwind native_libs
AIX should follow a similar path here to other libunwind platforms, with regards to system vs in-tree libunwind and the native lib search directories.
Having the right native lib search directories here is also required to get the correct default library search paths, due to some quirks of the AIX linker.
Stabilize `extended_varargs_abi_support`
I think that is everything? If there is any documentation regarding `extern` and/or varargs to correct, let me know, some quick greps suggest that there might be none.
Tracking issue: https://github.com/rust-lang/rust/issues/100189
Bump boostrap compiler to new beta
Currently failing due to something about the const stability checks and `panic!`. I'm not sure why though since I wasn't able to see any PRs merged in the past few days that would result in a `cfg(bootstrap)` that shouldn't be removed. cc `@RalfJung` #131349
Support `clobber_abi` in AVR inline assembly
This PR implements the `clobber_abi` part necessary to eventually stabilize the inline assembly for AVR. This is tracked in #93335.
This is heavily inspired by the sibling-PR #131310 for the MSP430. I've explained my reasoning in the first commit message in detail, which is reproduced below for easier reviewing:
This follows the [ABI documentation] of AVR-GCC:
> The [...] call-clobbered general purpose registers (GPRs) are registers that might be destroyed (clobbered) by a function call.
>
> - **R18–R27, R30, R31**
>
> These GPRs are call clobbered. An ordinary function may use them without restoring the contents. [...]
>
> - **R0, T-Flag**
>
> The temporary register and the T-flag in SREG are also call-clobbered, but this knowledge is not exposed explicitly to the compiler (R0 is a fixed register).
Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM.
Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways).
Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways.
[ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
r? ``@Amanieu``
``@rustbot`` label +O-AVR
This is currently handled automatically by the fact that codegen doesn't visit
coverage statements in unused functions, but that will no longer be the case
when unused IDs are identified by a separate query instead.
Rollup of 7 pull requests
Successful merges:
- #132782 (improvements on initial sysroot and libdir finding logics)
- #133466 (Fix typos in pin.rs)
- #133492 (bootstrap: allow skipping steps with start of path)
- #133501 (support revealing defined opaque post borrowck)
- #133530 (Use consistent wording in docs, use is zero instead of is 0)
- #133538 (Better diagnostic for fn items in variadic functions)
- #133590 (Rename `-Zparse-only`)
r? `@ghost`
`@rustbot` modify labels: rollup
support revealing defined opaque post borrowck
By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. ``@compiler-errors`` mentioned that always using existentials may be unsound.
r? ``@compiler-errors``
Remove `HybridBitSet`
`HybridBitSet` was introduced under the name `HybridIdxSetBuf` way back in #53383 where it was a big win for NLL borrow checker performance. In #93984 the more flexible `ChunkedBitSet` was added. Uses of `HybridBitSet` have gradually disappeared (e.g. #116152) and there are now few enough that they can be replaced with `BitSet` or `ChunkedBitSet`, and `HybridBitSet` can be removed, cutting more than 700 lines of code.
r? `@Mark-Simulacrum`
As part of the larger goal of reducing `HybridBitSet` use in general.
This code is for debugging only and isn't performance sensitive, so
`ChunkedBitSet` should be fine.
The current implementation is slow because it does an operation for
every bit in the set, even zero bits. So if you have a large bitset with
many zero bits (which is common) it's very slow.
This commit improves the iterator to skip over `Zeros` chunks in a
single step, and uses the fast `BitIter` for `Mixed` chunks. It also
removes the existing `fold` implementation, which was only there because
the old iterator was slow.
- Fix a typo in a comment.
- Remove unnecessary `Chunk::` qualifiers.
- Rename `ChunkedBitIter::bitset` as `ChunkedBitIter::bit_set`, because
`bit_set` is the form used everywhere else.
- Avoid some unnecessary local variables.
`ChunkedBitSet::is_empty` currently does an unnecessary check. This
commit removes that check and adds clarifying comments and an assertion
that demonstrate why it's unnecessary.
Revert #133418 (Store coverage source regions as `Span`) due to regression #133606
This reverts commit adf9b5fcd1, reversing changes made to af1ca153d4.
Reverting #133418 due to regressions reported at #133606.
r? jieyouxu
this implements checks necessary to guarantee that we can actually
perform a tail call. while extremely restrictive, this is what is
documented in the RFC, and all these checks are needed for one reason or
another.
ensure JSON-defined targets are consistent
We have a `check_consistency` check that ensures some invariants which (presumably) the rest of the compiler relies on. However, JSON targets can easily be written in a way that violates those invariants. So this PR applies the same consistency check to JSON targets that we already enforce for built-in targets.
I have converted many of the assertions in that function to new macros that show a nice error instead of a panic; if people are okay with the general approach here, I can do that for the rest of the checks as well.
Enable -Zshare-generics for inline(never) functions
This avoids inlining cross-crate generic items when possible that are
already marked inline(never), implying that the author is not intending
for the function to be inlined by callers. As such, having a local copy
may make it easier for LLVM to optimize but mostly just adds to binary
bloat and codegen time. In practice our benchmarks indicate this is
indeed a win for larger compilations, where the extra cost in dynamic
linking to these symbols is diminished compared to the advantages in
fewer copies that need optimizing in each binary.
It might also make sense it expand this with other heuristics (e.g.,
`#[cold]`) in the future, but this seems like a good starting point.
FWIW, I expect that doing cleanup in where we make the decision
what should/shouldn't be shared is also a good idea. Way too
much code needed to be tweaked to check this. But I'm hoping
to leave that for a follow-up PR rather than blocking this on it.
this is funny though! apparently tidy parsed `.gitignore`, but did not
recognize unignore lines (`!...`), so tidy was ignoring `rustc_mir_build`
this whole time (at least for some lints?).
I was surprised to find that running with `-Zparse-only` only parses the
crate root file. Other files aren't parsed because that happens later
during expansion.
This commit renames the option and updates the help message to make this
clearer.
This reduces code sizes and better respects programmer intent when
marking inline(never). Previously such a marking was essentially ignored
for generic functions, as we'd still inline them in remote crates.
When we encounter an error caused by traits/types of different versions of the same crate, filter out the current crate when collecting spans to add to the context so we don't call `extern_crate` on the `DefId` of the current crate, which is meaningless and ICEs.
Produced output with this filter:
```
error[E0277]: the trait bound `foo::Struct: Trait` is not satisfied
--> y.rs:13:19
|
13 | check_trait::<foo::Struct>();
| ^^^^^^^^^^^ the trait `Trait` is not implemented for `foo::Struct`
|
note: there are multiple different versions of crate `foo` in the dependency graph
--> y.rs:7:1
|
4 | extern crate foo;
| ----------------- one version of crate `foo` is used here, as a direct dependency of the current crate
5 |
6 | pub struct Struct;
| ----------------- this type implements the required trait
7 | pub trait Trait {}
| ^^^^^^^^^^^^^^^ this is the required trait
|
::: x.rs:4:1
|
4 | pub struct Struct;
| ----------------- this type doesn't implement the required trait
5 | pub trait Trait {}
| --------------- this is the found trait
= note: two types coming from two different versions of the same crate are different types even if they look the same
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `check_trait`
--> y.rs:10:19
|
10 | fn check_trait<T: Trait>() {}
| ^^^^^ required by this bound in `check_trait`
```
Fix#133563.
always create `DefId`s for anon consts
but don't use them anywhere, we intentionally don't encode them in the crate metadata.
best reviewed by disabling whitespace.
This pretty much reimplements #133285 while adding the tests of #133455. Fixes#133064
r? `@BoxyUwU` `@compiler-errors`
This commit adds the relevant registers to the list of clobbered regis-
ters (part of #93335). This follows the [ABI documentation] of AVR-GCC:
> The [...] call-clobbered general purpose registers (GPRs) are
> registers that might be destroyed (clobbered) by a function call.
>
> - **R18–R27, R30, R31**
>
> These GPRs are call clobbered. An ordinary function may use them
> without restoring the contents. [...]
>
> - **R0, T-Flag**
>
> The temporary register and the T-flag in SREG are also call-
> clobbered, but this knowledge is not exposed explicitly to the
> compiler (R0 is a fixed register).
Therefore this commit lists the aforementioned registers `r18–r27`,
`r30` and `r31` as clobbered registers. Since the `r0` register (listed
above as well) is not available in inline assembly at all (potentially
because the AVR-GCC considers it a fixed register causing the register
to never be used in register allocation and LLVM adopting this), there
is no need to list it in the clobber list (the `r0`-variant is not even
available). A comment was added to ensure, that the `r0` gets added to
the clobber-list once the register gets usable in inline ASM.
Since the SREG is normally considered clobbered anyways (unless the user
supplies the `preserve_flags`-option), there is no need to explicitly
list a bit in this register (which is not possible to list anyways).
Note, that this commit completely ignores the case of interrupts (that
are described in the ABI-specification), since every register touched in
an ISR need to be saved anyways.
[ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
Cargo's -Zbuild-std has recently started checking this field, which
causes it to fail to compile even though we have full support for the
standard library on these targets.
Small doc fixes in `rustc_codegen_ssa`
I'm trying to make a toy codegen backend for `rustc`, and I got confused for a few minutes about what `codegen_backend` was referring to in the `CodegenBackend::join_codegen` docs.
Experimentally, it looks like the result of `CodegenBackend::codegen_crate` is passed to `CodegenBackend::join_codegen`, so this updates the docs to refer to that. This time using intra-doc links to hopefully cause people to notice if that gets out of date again.
Also, added another intra-doc link nearby, on `CodegenBackend::link`, for the same reason.
Fix clobber_abi in RV32E and RV64E inline assembly
Currently clobber_abi in RV32E and RV64E inline assembly is implemented using InlineAsmClobberAbi::RiscV, but broken since x16-x31 cannot be used in RV32E and RV64E.
```
error: cannot use register `x16`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x17`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x28`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x29`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x30`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x31`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
```
r? `@Amanieu`
`@rustbot` label O-riscv +A-inline-assembly
Don't type error if we fail to coerce `Pin<T>` because it doesnt contain a ref
Fixes https://github.com/rust-lang/rust/issues/133222. Also moves some tests into a directory for better bookkeeping.
r? eholk or re-roll
`parse_expr_bottom` stores `this.token.span` in `lo`, but then fails to
use it in many places where it could. This commit fixes that, and
likewise (to a smaller extent) in `parse_ty_common`.
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
Structurally resolve before applying projection in borrowck
As far as I can tell, all other `.normalize` calls in borrowck are noops and can remain that way. This is the only one that actually requires structurally resolving the type.
r? lcnr
Check `xform_ret_ty` for WF in the new solver to improve method winnowing
This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:
```
impl Foo
where
WC1,
{
fn method()
where
WC2,
{}
}
```
We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)
This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?
r? lcnr
Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`
So in https://github.com/rust-lang/rust/pull/113182, I introduced a "diagnostics improvement" in the form of 473c88dfb6, which changes which signature we end up instantiating with placeholder regions and which signature we end up instantiating with fresh region vars so that we have placeholders corresponding to the names of the late-bound regions coming from the *impl*.
However, this is not sound, since now we're essentially no longer proving that *all* instantiations of the trait method are compatible with an instantiation of the impl method, but vice versa (which is weaker). Let's look at the example `tests/ui/impl-trait/in-trait/do-not-imply-from-trait-impl.rs`:
```rust
trait MkStatic {
fn mk_static(self) -> &'static str;
}
impl MkStatic for &'static str {
fn mk_static(self) -> &'static str { self }
}
trait Foo {
fn foo<'a: 'static, 'late>(&'late self) -> impl MkStatic;
}
impl Foo for str {
fn foo<'a: 'static>(&'a self) -> impl MkStatic + 'static {
self
}
}
fn call_foo<T: Foo + ?Sized>(t: &T) -> &'static str {
t.foo().mk_static()
}
fn main() {
let s = call_foo(String::from("hello, world").as_str());
println!("> {s}");
}
```
To collect RPITITs, we were previously instantiating the trait signature with infer vars (`fn(&'?0 str) -> ?1t` where `?1t` is the variable we use to infer the RPITIT) and the impl signature with placeholders (there are no late-bound regions in that signature, so we just have `fn(&'a str) -> Opaque`).
Equating the signatures works, since all we do is unify `?1t` with `Opaque` and `'?0` with `'a`. However, conceptually it *shouldn't* hold, since this definition is not valid for *all* instantiations of the trait method but just the one where `'0` (i.e. `'late`) is equal to `'a` :(
## So what
This PR effectively reverts 473c88dfb6 to fix the unsoundness.
Fixes#133427
Also fixes#133425, which is actually coincidentally another instance of this bug (but not one that is weaponized into UB, just one that causes an ICE in refinement checking).
Delay a bug when encountering an impl with unconstrained generics in `codegen_select`
Despite its name, `codegen_select` is what powers `Instance::try_resolve`, which is used in pre-codegen contexts to try to resolve a method where possible. One place that it's used is in the "recursion MIR lint" that detects recursive MIR bodies.
If we encounter an impl in `codegen_select` that contains unconstrained generic parameters, we expect that impl to caused an error to be reported; however, there's no temporal guarantee that this error is reported *before* we call `codegen_select`. This is what a delayed bug is *for*, and this PR makes us use a delayed bug rather than asserting something about errors already having been emitted.
Fixes #126646
Rollup of 5 pull requests
Successful merges:
- #132410 (Some more refactorings towards removing driver queries)
- #133418 (coverage: Store coverage source regions as `Span` until codegen)
- #133498 (Add missing code examples on `LocalKey`)
- #133518 (Structurally resolve before checking `!` in HIR typeck)
- #133521 (Structurally resolve before matching on type of projection)
r? `@ghost`
`@rustbot` modify labels: rollup
Structurally resolve before matching on type of projection
Another missing structural resolve in closure upvar analysis. I think it's better to place the normalization here rather than trying to guarantee that all types returned by the expr use visitor are structurally normalized, which I don't think we do now. Thoughts?
r? lcnr
coverage: Store coverage source regions as `Span` until codegen
Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead.
In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32.
---
There should be no changes to coverage output.
Some more refactorings towards removing driver queries
Follow up to https://github.com/rust-lang/rust/pull/127184
## Custom driver breaking change
The `after_analysis` callback is changed to accept `TyCtxt` instead of `Queries`. The only safe query in `Queries` to call at this point is `global_ctxt()` which allows you to enter the `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `tcx: TyCtxt<'tcx>` and remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
## Custom driver deprecation
The `after_crate_root_parsing` callback is now deprecated. Several custom drivers are incorrectly calling `queries.global_ctxt()` from inside of it, which causes some driver code to be skipped. As such I would like to either remove it in the future or if custom drivers still need it, change it to accept an `&rustc_ast::Crate` instead.
Recover some lost performence from #132732
This PR reorders some conditions in the `dangling_pointers_from_temporaries` lint to avoid some potentially expensive query call, in particular those who could involve some metadata decoding from disk.
cc https://github.com/rust-lang/rust/pull/132732#issuecomment-2499990683
cc `@Kobzol`
Some minor dyn-related tweaks
Each commit should be self-explanatory, but I'm happy to explain what's going on if not. These are tweaks I pulled out of #133388, but they can be reviewed sooner than that.
r? types
Allow injecting a profiler runtime into `#![no_core]` crates
An alternative to #133300, allowing `-Cinstrument-coverage` to be used with `-Zbuild-std`.
The incompatibility between `profiler_builtins` and `#![no_core]` crates appears to have been caused by profiler_builtins depending on core, and therefore conflicting with core (or minicore).
But that's a false dependency, because the profiler doesn't contain any actual Rust code. So we can just mark the profiler itself as `#![no_core]`, and remove the incompatibility error.
---
For context, the error was originally added by #79958.
do not constrain infer vars in `find_best_leaf_obligation`
This ended up causing an ICE by making the following code path reachable by incorrectly constraining an inference variable while computing the best obligation for a preceding ambiguity. Closes#129444.
f2abf827c1/compiler/rustc_trait_selection/src/solve/fulfill.rs (L312-L314)
I have to be honest, I don't fully understand how that change removes all the additional diagnostics :3
r? `@compiler-errors`
Use edition of `macro_rules` when compiling the macro
This changes the edition assigned to a macro_rules macro when it is compiled to use the edition of where the macro came from instead of the local crate's edition.
This fixes a problem when a macro_rules macro is created by a proc-macro. Previously that macro would be tagged with the local edition, which would cause problems with using the correct edition behavior inside the macro. For example, the check for unsafe attributes would cause errors in 2024 when using proc-macros from older editions.
This is partially related to https://github.com/rust-lang/rust/issues/132906. Unfortunately this is only a half fix for that issue. It fixes the error that happens in 2024, but does not fix the lint firing in 2021. I'm still trying to think of some way to fix that, but I'm running low on ideas.
Revert diagnostics hack to fix ICE 132920
This reverts 8a568d9f15 from #128849 to fix the diagnostics ICE in #132920.
The hack mentioned in that commit was supposed to be tailored to E277, but that codepath is used actually shared with other errors, e.g. at least the E283 from the linked issue.
We may have to eat the slightly worse diagnostics until a non-hacky way to make this error less verbose is implemented (or I guess a different hack specializing even more to E277's structure).
Sorry ``@estebank`` 🙏. I can close this if you'd prefer to fix it in a different way.
Since it seems unexpected that #128849 would impact the repro, here's how the error used to look before that PR.
```console
warning: unused import: `minirapier::Ray`
--> src/main.rs:2:5
|
2 | use minirapier::Ray;
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
error[E0283]: type annotations needed
--> src/main.rs:10:5
|
10 | insert_resource(Res.into());
| ^^^^^^^^^^^^^^^ ---------- type must be known at this point
| |
| cannot infer type of the type parameter `R` declared on the function `insert_resource`
|
= note: cannot satisfy `_: Resource`
= help: the trait `Resource` is implemented for `Res`
note: required by a bound in `insert_resource`
--> src/main.rs:4:23
|
4 | fn insert_resource<R: Resource>(_resource: R) {}
| ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
|
10 | insert_resource::<R>(Res.into());
| +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
|
10 - insert_resource(Res.into());
10 + insert_resource(Res);
```
And how it looks now without the ICE.
```console
warning: unused import: `minirapier::Ray`
--> src/main.rs:2:5
|
2 | use minirapier::Ray;
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
error[E0283]: type annotations needed
--> src/main.rs:10:5
|
10 | insert_resource(Res.into());
| ^^^^^^^^^^^^^^^ ---------- type must be known at this point
| |
| cannot infer type of the type parameter `R` declared on the function `insert_resource`
|
= note: cannot satisfy `_: Resource`
note: there are multiple different versions of crate `minibevy` in the dependency graph
--> /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_b/src/lib.rs:1:1
|
1 | pub trait Resource {}
| ^^^^^^^^^^^^^^^^^^ this is the required trait
|
::: src/main.rs:1:5
|
1 | use minibevy::Resource;
| -------- one version of crate `minibevy` is used here, as a direct dependency of the current crate
2 | use minirapier::Ray;
| ---------- one version of crate `minibevy` is used here, as a dependency of crate `minirapier`
|
::: /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_a/src/lib.rs:1:1
|
1 | pub trait Resource {}
| ------------------ this is the found trait
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `insert_resource`
--> src/main.rs:4:23
|
4 | fn insert_resource<R: Resource>(_resource: R) {}
| ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
|
10 | insert_resource::<R>(Res.into());
| +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
|
10 - insert_resource(Res.into());
10 + insert_resource(Res);
|
```
The improvements from #128849 are still present and the note about the trait coming from the 2 versions of bevy is more explanatory/helpful than before, albeit a bit verbosely.
Fixes#132920.
Remove -Zfuel.
I'm not sure this feature is used. I only found 2 references in a google search, both referring to its introduction.
Meanwhile, it's a global mutable state, untracked by incremental compilation, so incompatible with it.
Bail on more errors in dyn ty lowering
If we have more than one principal trait, or if we have a principal trait with errors in it, then bail with `TyKind::Error` rather than attempting lowering. Lowering a dyn trait with more than one principal just arbitrarily chooses the first one and drops the subsequent ones, and lowering a dyn trait path with errors in it is just kinda useless.
This suppresses unnecessary errors which I think is net-good, but also is important to make sure that we don't end up leaking `{type error}` in https://github.com/rust-lang/rust/issues/133388 error messaging :)
r? types
Simplify array length mismatch error reporting (to not try to turn consts into target usizes)
This changes `TypeError::FixedArrayLen` to use `ExpectedFound<ty::Const<'tcx>>` (instead of `ExpectedFound<u64>`), and renames it to `TypeError::ArrayLen`. This allows us to avoid a `try_to_target_usize` call in the type relation, which ICEs when we have a scalar of the wrong bit length (i.e. u8).
This also makes `structurally_relate_tys` to always use this type error kind any time we have a const mismatch resulting from relating the array-len part of `[T; N]`.
This has the effect of changing the error message we issue for array length mismatches involving non-valtree consts. I actually quite like the change, though, since before:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected `M`, found `N`
|
= note: expected array `[u8; M]`
found array `[u8; N]`
```
and after, which I think is far less verbose:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected an array with a size of M, found one with a size of N
```
The only questions I have are:
1. Should we do something about backticks here? Right now we don't backtick either fully evaluated consts like `2`, or rigid consts like `Foo::BAR`.... but maybe we should? It seems kinda verbose to do for numbers -- maybe we could intercept those specifically.
2. I guess we may still run the risk of leaking unevaluated consts into error reporting like `2 + 1`...?
r? ``@BoxyUwU``
Fixes#126359Fixes#131101
No need to re-sort existential preds in relate impl
We already assert that these predicates are in the right ordering in `mk_poly_existential_predicates`.
r? types
Remove the `DefinitelyInitializedPlaces` analysis.
Its only use is in the `tests/ui/mir-dataflow/def_inits-1.rs` where it is tested via `rustc_peek_definite_init`.
Also, it's probably buggy. It's supposed to be the inverse of `MaybeUninitializedPlaces`, and it mostly is, except that `apply_terminator_effect` is a little different, and `apply_switch_int_edge_effects` is missing. Unlike `MaybeUninitializedPlaces`, which is used extensively in borrow checking, any bugs in `DefinitelyInitializedPlaces` are easy to overlook because it is only used in one small test.
This commit removes the analysis. It also removes
`rustc_peek_definite_init`, `Dual` and `MeetSemiLattice`, all of which are no longer needed.
r? ``@cjgillot``
Inline ExprPrecedence::order into Expr::precedence
The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).
Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:
1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`
As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.
The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:
```rust
match self.kind {
ExprKind::Closure(..) => ExprPrecedence::Closure,
...
}
```
although there were exceptions of both many-to-one, and one-to-many:
```rust
ExprKind::Underscore => ExprPrecedence::Path,
ExprKind::Path(..) => ExprPrecedence::Path,
...
ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```
Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.
You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:
- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.
- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.
- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.
This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
Use ReadCache for archive reading in bootstrap
Address expensive archive reading in bootstrap. This fixes https://github.com/rust-lang/rust/issues/133268
Enable the `std` feature of `object` to use `ReadCache` instead of reading the entire archive file into memory to check for headers. This takes minimal extra time to compile compared to introducing other expensive dependencies to `bootstrap`.
r? jieyouxu
Tweak parameter mismatch explanation to not say `{unknown}`
* Tweak parameter mismatch explanation not to call parameters with no identifier `{unknown}`
* Say "both" when there are two parameters
* Backtick a type parameter name for consistency
the emscripten OS no longer exists on non-wasm targets
https://github.com/rust-lang/rust/pull/117338 removed our asmjs targets, which AFAIK means that emscripten only exists on wasm targets. However at least one place in the code still checked "is wasm or is emscripten". Let's fix that.
Cc ```@workingjubilee```
Refactor `where` predicates, and reserve for attributes support
Refactor `WherePredicate` to `WherePredicateKind`, and reserve for attributes support in `where` predicates.
This is a part of #115590 and is split from #132388.
r? petrochenkov
`ResultsCursor` currently owns its `Results`. But sometimes the
`Results` is needed again afterwards. So there is
`ResultsCursor::into_results` for extracting the `Results`, which leads
to some awkwardness.
This commit adds `ResultsHandle`, a `Cow`-like type that can either
borrow or own a a `Results`. `ResultsCursor` now uses it. This is good
because some `ResultsCursor`s really want to own their `Results`, while
others just want to borrow it.
We end with with a few more lines of code, but get some nice cleanups.
- `ResultsCursor::into_results` and `Formatter::into_results` are
removed.
- `write_graphviz_results` now just borrows a `Results`, instead of the
awkward "take ownership of a `Results` and then return it unchanged"
pattern.
This reinstates the cursor flexibility that was lost in #118230 -- which
removed the old `ResultsRefCursor` and `ResultsCloneCursor` types -- but
in a much simpler way. Hooray!
In `MaybeRequiresStorage::apply_before_statement_effect`, call
`transfer_function` directly, as is already done in
`MaybeRequiresStorage::apply_before_terminator_effect`. This makes it clear
that the operation doesn't rely on the `MaybeBorrowedLocals` results.
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.
This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |
This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313
In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.
Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.
cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm
`@rustbot` label +O-SystemZ +A-inline-assembly
Fix asm goto with outputs and move it to a separate feature gate
Tracking issue: #119364
This PR addresses 3 aspects of asm goto with outputs:
* Codegen is fixed. My initial implementation has an oversight which cause the output to be only stored in fallthrough path, but not in label blocks.
* Outputs can now be used with `options(noreturn)` if a label block is given.
* All of this is moved to a new feature gate, because we likely want to stabilise `asm_goto` before asm goto with outputs.
`@rustbot` labels: +A-inline-assembly +F-asm
There is a not-very-useful layering in the lexer, where
`TokenTreesReader` contains a `StringReader`. This commit combines them
and names the result `Lexer`, which is a more obvious name for it.
The methods of `Lexer` are now split across `mod.rs` and `tokentrees.rs`
which isn't ideal, but it doesn't seem worth moving a bunch of code to
avoid it.
add a test for target-feature-ABI warnings in closures and when calling extern fn
Also update the comment regarding the inheritance of target features into closures, to make it more clear that we really shouldn't do this right now.
only store valid proc macro item for doc link
Fixes#132743
The definition item can be detected if it is exported in the doc, so store these items rather than skipping.
r? `@petrochenkov`
When labels are present, the `noreturn` option really means that asm block
won't fallthrough -- if labels are present, then outputs can still be
meaningfully used.
