Do not use effective_visibilities query for Adt types of a local trait while proving a where-clause
Partially fixrust-lang/rust#145611, but we should do something make cycle in this situation ICE.
Instead of using a query, call `&tcx.resolutions(()).effective_visibilities`.
r? `````@lcnr`````
cc `````@compiler-errors`````
Unconditionally-const supertraits are considered not dyn compatible
Let's save some space in the design of const traits by making `dyn Trait` where `trait Trait: const Super` not dyn compatible.
Such a trait cannot satisfy `dyn Trait: Trait`; we could in the future make this dyn compatible but *NOT* implement `Trait`, but that's a bit weird and seems like it needs to be independently justified moving forward.
Fixes https://github.com/rust-lang/rust/issues/145198
r? fee1-dead
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
Shorten some dependency chains in the compiler
(I recommend reviewing this commit by commit.)
One of the long dependency chains in the compiler is:
- Many things depend on `rustc_errors`.
- `rustc_errors` depended on many things prior to this PR, including `rustc_target`, `rustc_type_ir`, `rustc_hir`, and `rustc_lint_defs`.
- `rustc_lint_defs` depended on `rustc_hir` prior to this PR.
- `rustc_hir` depends on `rustc_target`.
- `rustc_target` is large and takes a while.
This PR breaks that chain, through a few steps:
- The `IntoDiagArgs` trait, from `rustc_errors`, moves earlier in the dependency chain. This allows `rustc_errors` to stop depending on a pile of crates just to implement `IntoDiagArgs` for their types.
- Split `rustc_hir_id` out of `rustc_hir`, so crates that just need `HirId` and similar don't depend on all of `rust_hir` (and thus `rustc_target`).
- Make `rustc_lint_defs` stop depending on `rustc_hir`.
fix(debuginfo): handle false positives in overflow check
Fixesrust-lang/rust#144636.
Duplicate wrappers and normal recursive types can lead to false positives.
```rust
struct Recursive {
a: Box<Box<Recursive>>,
}
```
The ADT stack can be:
- `Box<Recursive>`
- `Recursive`
- `Box<Box<Recursive>>` (`Box` now detected as expanding)
We can filter them out by tracing the generic arg back through the stack, as true expanding recursive types must have their expanding arg used as generic arg throughout.
r? ````@wesleywiser````
Defer tail call ret ty equality to check_tail_calls
Fixesrust-lang/rust#144892.
Currently the tail call signature check assumes that return types have been accounted for. However, this is not complete for several reasons.
Firstly, we were using subtyping instead of equality in the HIR typeck code:
e1b9081e69/compiler/rustc_hir_typeck/src/expr.rs (L1096)
We could fix this, but it doesn't really do much for us anyways since HIR typeck doesn't care about regions.
That means, secondly, we'd need to fix the terminator type check in MIR typeck to account for variances, since tail call terminators need to relate their arguments invariantly to account for the "signature must be equal" rule. This seems annoying.
All of this seems like a lot of work, and we already are *manually* checking argument equality. Let's just extend the `check_tail_calls` to account for mismatches in return types anyways.
r? ``````@WaffleLapkin``````
support non-defining uses of opaques in borrowck
Reimplements the first part of rust-lang/rust#139587, but limited to only the new solver. To do so I also entirely rewrite the way we handle opaque types in borrowck even on stable. This should not impact behavior however.
We now support revealing uses during MIR borrowck with the new solver:
```rust
fn foo<'a>(x: &'a u32) -> impl Sized + use<'a> {
let local = 1;
foo::<'_>(&local);
x
}
```
### How do opaque types work right now
Whenever we use an opaque type during type checking, we remember this use in the `opaque_type_storage` of the `InferCtxt`.
Right now, we collect all *member constraints* at the end of MIR type check by looking at all uses from the `opaque_type_storage`. We then apply these constraints while computing the region values for each SCC. This does not add actual region constraints but directly updates the final region values.
This means we need to manually handle any constraints from member constraints for diagnostics. We do this by separately tracking `applied_member_constraints` in the `RegionInferenceContext`.
After we've finished computing the region values, it is now immutable and we check whether all member constraints hold. If not, we error.
We now map the hidden types of our defining uses to the defining scope. This assumes that all member constraints apply. To handle non-member regions, we simply map any region in the hidden type we fail to map to a choice region to `'erased` b1b26b834d/compiler/rustc_borrowck/src/region_infer/opaque_types.rs (L126-L132)
### How do we handle opaque types with this PR
MIR type check still works the same by populating the `opaque_type_storage` whenever we use an opaque type.
We now have a new step `fn handle_opaque_type_uses` which happens between MIR type check and `compute_regions`.
This step looks at all opaque type uses in the storage and first checks whether they are defining: are the arguments of the `opaque_type_key` unique region parameters. *With the new solver we silently ignore any *non-defining* uses here. The old solver emits an errors.*
`fn compute_concrete_opaque_types`: We then collect all member constraints for the defining uses and apply them just like we did before. However, we do it on a temporary region graph which is only used while computing the concrete opaque types. We then use this region graph to compute the concrete type which we then store in the `root_cx`.
`fn apply_computed_concrete_opaque_types`: Now that we know the final concrete type of each opaque type and have mapped them to the definition of the opaque. We iterate over all opaque type uses and equate their hidden type with the instantiated final concrete type. This is the step which actually mutates the region graph.
The actual region checking can now entirely ignores opaque types (outside of the `ConstraintCategory` from checking the opaque type uses).
### Diagnostics issue (chill)
Because we now simply use type equality to "apply member constraints" we get ordinary `OutlivesConstraint`s, even if the regions were already related to another.
This is generally not an issue, expect that it can *hide* the actual region constraints which resulted in the final value of the opaque. The constraints we get from checking against the final opaque type definition relies on constraints we used to compute that definition.
I mostly handle this by updating `find_constraint_path_between_regions` to first ignore member constraints in its search and only if that does not find a path, retry while considering member constraints.
### Diagnostics issue (not chill)
A separate issue is that `find_constraint_paths_between_regions` currently looks up member constraints by their **scc**, not by region value:
2c1ac85679/compiler/rustc_borrowck/src/region_infer/mod.rs (L1768-L1775)
This means that in the `borrowck-4` test, the resulting constraint path is currently
```
('?2: '?5) due to Single(bb0[5]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?5: '?3) due to Single(bb0[6]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?3: '?0) due to All(src/main.rs:15:5: 15:6 (#0)) (None) (OpaqueType) (ConstraintSccIndex(1): ConstraintSccIndex(1))
```
Here `'?3` is equal to `'?4`, but the reason why it's in the opaque is that it's related to `'?4`. With my PR this will be correctly tracked so we end up with
```
('?2: '?5) due to Single(bb0[5]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?5: '?3) due to Single(bb0[6]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?3: '?4) due to Single(bb0[6]) (None) (Assignment) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?4: '?0) due to All(src/main.rs:15:5: 15:6 (#0)) (None) (OpaqueType) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
```
This additional `Assignment` step then worsens the error message as we stop talking about the fact that the closures is returned from the function. Fixing this is hard. I've looked into this and it's making me sad :< Properly handling this requires some deeper changes to MIR borrowck diagnostics and that seems like too much for this PR. Given that this only impacts a single test, it seems acceptable to me.
r? `@ghost`
Tell LLVM about read-only captures
`&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
`rustc_lint_defs` uses `rustc_hir` solely for the `Namespace` type,
which it only needs the static description from. Use the static
description directly, to eliminate the dependency on `rustc_hir`.
This reduces a long dependency chain:
- Many things depend on `rustc_errors`
- `rustc_errors` depends on `rustc_lint_defs`
- `rustc_lint_defs` depended on `rustc_hir` prior to this commit
- `rustc_hir` depends on `rustc_target`
Some crates depend on `rustc_hir` but only want `HirId` and similar id
types. `rustc_hir` is a heavy dependency, since it pulls in
`rustc_target`. Split these types out into their own crate
`rustc_hir_id`.
This allows `rustc_errors` to drop its direct dependency on `rustc_hir`.
(`rustc_errors` still depends on `rustc_hir` indirectly through
`rustc_lint_defs`; a subsequent commit will fix that.)
`rustc_errors` depends on numerous crates, solely to implement its
`IntoDiagArg` trait on types from those crates. Many crates depend on
`rustc_errors`, and it's on the critical path.
We can't swap things around to make all of those crates depend on
`rustc_errors` instead, because `rustc_errors` would end up in
dependency cycles.
Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far
fewer dependencies, and then have most of these crates depend on
`rustc_error_messages`.
This allows `rustc_errors` to drop dependencies on several crates,
including the large `rustc_target`.
(This doesn't fully reduce dependency chains yet, as `rustc_errors`
still depends on `rustc_hir` which depends on `rustc_target`. That will
get fixed in a subsequent commit.)
`&Freeze` parameters are not only `readonly` within the function,
but any captures of the pointer can also only be used for reads.
This can now be encoded using the `captures(address, read_provenance)`
attribute.
add a fallback implementation for the `prefetch_*` intrinsics
related ACP: https://github.com/rust-lang/libs-team/issues/638
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic)
Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type.
Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op).
cc `@Amanieu`
r? `@RalfJung`
Pretty print the name of an future from calling async closure
Fixes https://github.com/rust-lang/rust/issues/145606 by introducing a way to customize the path rendering of async closures' futures in the pretty printer API.
Demote x86_64-apple-darwin to Tier 2 with host tools
Switch to only using aarch64 runners (implying we are now cross-compiling) and stop running tests. In the future, we could enable (some?) tests via Rosetta 2.
This implements the decision from https://github.com/rust-lang/rfcs/pull/3841.
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
Add VEXos "linked files" support to `armv7a-vex-v5`
Third-party programs running on the VEX V5 platform need a linker script to ensure code and data are always placed in the allowed range `0x3800000-0x8000000` which is read/write/execute. However, developers can also configure the operating system (VEXos) to preload a separate file at any location between these two addresses before the program starts (as a sort of basic linking or configuration loading system). Programs have to know about this at compile time - in the linker script - to avoid placing data in a spot that overlaps where the linked file will be loaded. This is a very popular feature with existing V5 runtimes because it can be used to modify a program's behavior without re-uploading the entire binary to the robot controller.
It's important for Rust to support this because while VEXos's runtime user-exposed file system APIs may only read data from an external SD card, linked files are allowed to load data directly from the device's onboard storage.
This PR adds the `__linked_file_start` symbol to the existing VEX V5 linker script which can be used to shrink the stack and heap so that they do not overlap with a memory region containing a linked file. It expects the linked file to be loaded in the final N bytes of user RAM (this is not technically required but every existing runtime does it this way to avoid having discontinuous memory regions).
With these changes, a developer targeting VEX V5 might add a second linker script to their project by specifying `-Clink-arg=-Tcustom.ld` and creating the file `custom.ld` to configure their custom memory layout. The linker would prepend this to the builtin target linker script.
```c
/* custom.ld: Reserves 10MiB for a linked file. */
/* (0x7600000-0x8000000) */
__linked_file_length = 10M;
/* The above line is equivalent to -Clink-arg=--defsym=__linked_file_length=10M */
/* Optional: specify one or more sections that */
/* represent the developer's custom format. */
SECTIONS {
.linked_file_metadata (NOLOAD) : {
__linked_file_metadata_start = .;
. += 1M;
__linked_file_metadata_end = .;
}
.linked_file_data (NOLOAD) : {
__linked_file_data_start = .;
. += 9M;
__linked_file_data_end = .;
}
} INSERT AFTER .stack;
```
Then, using an external tool like the `vex-v5-serial` crate, they would configure the metadata of their uploaded program to specify the path of their linked file and the address where it should be loaded into memory (in the above example, `0x7600000`).
ignore frontmatters in `TokenStream::new`
Fixesrust-lang/rust#145520 for now, we'd likely want to figure the stripping part later, so I noted it down on the list on the tracking issue.
cc `@fmease`
Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.
This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.
```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]
use std::marker::MetaSized;
fn foo<T: !MetaSized>() {}
fn bar<T: !Sized + MetaSized>() {
foo::<T>();
//~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```
Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".
This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).
cc `@davidtwco` for `feature(sized_hierarchy)`
Maybe similar to 91c53c9 from <https://github.com/rust-lang/rust/pull/143307>
Visit and print async_fut local for async drop.
This is a bugfix for a MIR local we forget to visit.
I had a lot of trouble reading the docs for `async_fut`, so I'm not certain about the change to the pretty-printer.
Port must_use to the new target checking
This PR ports `must_use` to the new target checking logic
This also adds a tool-only suggestion to remove attributes on invalid targets, as to not immediately undo the work of https://github.com/rust-lang/rust/pull/145274
r? `@jdonszelmann`
remove `should_render` in `PrintAttribute` derive
It just seems to be always `true`, so don't do extra work emitting extra logic just for a `true`.
cc `@jdonszelmann`
Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups
Fixes https://github.com/rust-lang/rust/issues/145470.
First commit fixes the issue, second one performs some desperately needed cleanups.
The fix shouldn't be a breaking change because IINM the parser always ensures that all brackets are balanced (via a buffer of brackets). Meaning even though we used to accept `(use<>` as a valid precise capturing list, it was guaranteed that we would fail in the end.
