Add `const_param_ty_unchecked` gate
Add `const_param_ty_unchecked` internal feature gate to skip `ConstParamTy_` trait enforcement on type. Provides an escape hatch for writing tests and examples that use const generics without needing to ensure all fields implement `ConstParamTy_`.
r? BoxyUwU
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
refactor rustc_on_unimplemented's filtering
Previously when you had a
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub condition: Option<OnUnimplementedCondition>,
pub subcommands: ThinVec<Directive>,
pub message: Option<(Span, FormatString)>,
...
}
```
that condition would control the emission of the message, label, notes etc. I've changed that to
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub filters: ThinVec<(Filter, Directive)>,
pub message: Option<(Span, FormatString)>,
...
```
so that the message etc is always emitted, and there's a vec of tuples with (filter, directive) where the filter controls whether that directive is even emitted, which i think is much clearer. That also makes it easier to not have to do the reverse iteration thing and this makes it so that notes are emitted in declaration order (with nonfiltered options always last).
The rename is because I plan on making it available to other diagnostic attributes at some point (very wip) so `OnUnimplementedCondition` and the like would have to be renamed anyway.
Suggest `[const] Trait` bounds in more places
Right now we have some special logic in the const checker for emitting `[const] Trait` suggestions, but I'm trying to handle that similarly to how it is handled for normal `Trait` clauses. This is just a small step in how it will look on the UX side, which should make my follow-up PRs affect tests less and just be a refactoring
Change `ItemKind::Trait` to a field variant.
This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.
I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
Fix pathological performance in trait solver cycles with errors
Fuchsia's Starnix system has had a multi-year long bug where occasionally a typo could cause the rust compiler to take 10+ hours to report an error (see rust-lang/rust#136516 and rust-lang/rust#150907). This was particularly hard to trace down since Starnix's codebase is massive, over 384 thousand lines as of writing.
With the help of treereduce, cargo-minimize, and rustmerge, after about a month of running we reduced it down to a couple [lines of code], which only takes about 35 seconds to report an error on my machine. The bug also appears to happen with `-Z next-solver=no` and `-Z next-solver=coherence`, but does not occur with `-Z next-solver` or `-Z next-solver=globally`.
I used Gemini to help diagnose the problem and proposed solution (which is the one proposed in this patch):
1. The trait solver gets stuck in an exponential loop evaluating auto-trait bounds (like Send and Sync) on cyclic types that contain compilation errors (TyKind::Error).
2. Normally, if the solver detects a cycle, it prevents the result from being stored in the Global Cache because the result depends on the current evaluation stack. However, when an error is involved, the depth tracking gets pinned to a low value, forcing the solver to rely on the short-lived Provisional Cache. Since the provisional cache is cleared between high-level iterations of the fulfillment loop, the solver ends up re-discovering and re-evaluating the same large cycle thousands of times.
3. Allow global caching of results even if they appear stack-dependent, provided that the inference context is already "tainted by errors" (`self.infcx.tainted_by_errors().is_some()`). This violates the strict invariant that global cache entries shouldn't depend on the stack, but it is safe because the compilation is already guaranteed to fail due to the presence of errors. Prioritizing compiler responsiveness and termination over perfect correctness in error states is the correct trade-off here.
I added the reduction as the test case for this. However, I don't see an easy way to catch if this bug comes back. Should we add some way to timeout the test if it takes longer than 10 seconds to compile? That could be a source of flakes though.
I don't have any experience with the trait solver code, but I did try to review the code to the best of my ability. This approach seems a bit of a bandaid to the solution, but I don't see a better solution. We could try to teach the solver to not clear the provisional cache in this circumstance, but I suspect that'd be a pretty invasive change.
I'm guessing if this does cause problems, it might report an incorrect error, but I (and Gemini) were unable to come up with an example that reported a different error with and without this fix.
Resolvesrust-lang/rust#150907
[lines of code]: https://gist.github.com/erickt/255bc4006292cac88de906bd6bd9220a
Permit `{This}` in diagnostic attribute format literals
My motivation was that yesterday I wanted to write something like this and reference `$name` in the string literal.
```rust
pub mod sym {
// stuff here
}
macro_rules! my_macro {
($name:ident $(,)?) => {{
#[diagnostic::on_unknown(
message = "this is not present in symbol table",
note = "you must add it to rustc_span::symbol::symbol!"
)]
use sym::$name as name;
// ...
}}
}
```
That is (as far as I can tell) impossible or at least very unergonomic. This adds the ability to just reference the name of the item the attribute is on. I imagine that's useful for use inside macros generally, so it's also added for some other attributes.
The affected attributes are all unstable, it is not implemented for diagnostic::on_unimplemented (will do in its own PR).
Note that `{This}` is already usable in `#[rustc_on_unimplemented]`, so this does not implement it but just enables some more.
This PR also migrates one lint away from AttributeLintKind, and improves the messages for that lint.
Do not suggest borrowing enclosing calls for nested where-clause obligations
In rust-lang/rust#155088, the compiler was blaming the whole call expr instead of the value that actually failed the trait bound, so for foo(&[String::from("a")]) it was suggesting stuff like &foo(...). I changed the suggestion logic so it only emits borrow help if the expr it found actually matches the failed self type, and used the same check for the “similar impl exists” help too. So now the compiler should give the normal error + required bound note.
Fixrust-lang/rust#155088
Change keyword order for `impl` restrictions
Based on rust-lang/rust#155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`.
Tracking issue for restrictions: rust-lang/rust#105077
r? @Urgau
cc @jhpratt
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#155589 (Forbid `check-pass`/`build-pass`/`run-pass` directives in incremental tests)
- rust-lang/rust#155610 (Add missing `dyn` keyword to `trait_alias` page of the Unstable Book)
- rust-lang/rust#155615 (test cleanups for `ui/derives` and `ui/deriving`)
- rust-lang/rust#154874 (Fix ICE for inherited const conditions on const closures)
- rust-lang/rust#155605 (std: Update support for `wasm32-wasip3`)
- rust-lang/rust#155613 (c-variadic: tweak `std` docs)
- rust-lang/rust#155619 (Remove a bunch of unnecessary explicit lifetimes from the ast validator)
Fix ICE for inherited const conditions on const closures
Synchronize `evaluate_host_effect_for_fn_goal` with the behavior of `extract_fn_def_from_const_callable` in new solver.
Closesrust-lang/rust#153861 .
Remove duplicated `Flags` methods.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`. Multiple types impl this trait and then also have duplicate inherent methods with the same names; these are all marked with "Think about removing this" comments. This is left over from things being moved into `rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use Flags` to a number of files.
r? @lcnr
Suggest removing `&` when awaiting a reference to a future
Fixesrust-lang/rust#87211
When `.await`ing `&impl Future`, suggest removing the `&` instead of removing `.await`.
Make E0284 generic argument suggestions more explicit
Closesrust-lang/rust#147313
Previously, when type annotations were missing for a function call, rust suggested: "consider specifying the generic argument". This PR improves the diagnostics:
- If only one generic type is missing:
"consider specifying a concrete type for the generic type `<T>`" with the turbofish being "::\<SomeConcreteType>"
- If only one const generic is missing:
"consider specifying a const for the const generic `<CONST>`" with the turbofish being "::<SOME_CONST>"
Multiple missing generics still produce the original more general suggestion
Suggest returning a reference for unsized place from a closure
Fixesrust-lang/rust#152064
There are 3 similar note:
`the size for values of type str cannot be known at compilation time`
for different spans, maybe need more work to remove some of them.
This PR only adds a suggestion for using a reference.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`.
Multiple types impl this trait and then also have duplicate inherent
methods with the same names; these are all marked with "Think about
removing this" comments. This is left over from things being moved into
`rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use
Flags` to a number of files.
Nicholas Nethercote