Gate static closures behind a parser feature
I'd like to gate `static ||` closures behind a feature gate, since we shouldn't allow people to take advantage of this syntax if it's currently unstable. Right now, since it's only rejected after ast lowering, it's accessible to macros.
Let's crater this to see if we can claw it back without breaking anyone's code.
Add a method to dump MIR in the middle of MIR building
This makes it easier to debug issues with MIR building by inserting dump_for_debugging calls around the suspected code responsible for the bad MIR.
aarch64-nintendo-switch-freestanding - Enable CPU features that are always available in a live system (crypto instructions, plus explicit NEON).
~~While some NEON and crypto features may not be supported on the Nintendo Switch at boot (e.g. on the a53 cores) and this has not been tested, the features will _always_ be available if running as a sysmodule or homebrew application under Horizon/Atmosphere.~~ EDIT: the a53 cores are fused out, these features are always available.
This has been tested with local tools personally, as well as building [emuiibo](https://github.com/XorTroll/emuiibo) as it uses both `sha` and `aes` primitives. This was tested using inline assembly in previous versions, and in current versions by using the `aes`, `ctr`, `hmac`, and `sha2` crates.
r? `@jam1garner`
This ended up being much delayed from our discussions about updating this. I tested a number of individual features such as the `aes` and `sha2` target-features directly to avoid a warning message with the `crypto` feature, but that appears to be caused by https://github.com/rust-lang/rust/issues/96472 and is not actually an issue.
There is also a decision to make here about explicitly enabling the `neon` feature. I am in favor of it to be explicit, but it is not necessary as it is already enabled by the `v8a` and `crypto` features. I will defer to your decision as it does not change the actual instructions available for codegen.
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`
```
