New const traits syntax
This PR only affects the AST and doesn't actually change anything semantically.
All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser
Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error
r? ``@fee1-dead``
cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
Add note to `find_const_ty_from_env`
Add a note to `find_const_ty_from_env` to explain why it has an `unwrap` which "often" causes ICEs.
Also, uplift it into the new trait solver. This avoids needing to go through the interner to call this method which is otherwise an inherent method in the compiler. I can remove this part if desired.
r? `@boxyuwu`
[perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation
First compute hard errors without diagnostics, then ambiguities with diagnostics since we need to know if any of them overflowed.
Remove some glob imports from the type system
Namely, remove the glob imports for `BoundRegionConversionTime`, `RegionVariableOrigin`, `SubregionOrigin`, `TyOrConstInferVar`, `RegionResolutionError`, `SelectionError`, `ProjectionCandidate`, `ProjectionCandidateSet`, and some more specific scoped globs (like `Inserted` in the impl overlap graph construction.
These glob imports are IMO very low value, since they're not used nearly as often as other globs (like `TyKind`).
const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns
This fixes https://github.com/rust-lang/rust/issues/140653 by accepting code such as this:
```rust
static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;
```
This can be written entirely in safe code, so there can't really be anything wrong with it.
We also accept the much more questionable following code, since it looks very similar to the interpreter:
```rust
static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };
```
Using this without causing UB is at least very hard (the details are unclear since it is related to how the aliasing model deals with the staging of const-eval vs runtime code).
If a constant like `C2` is used as a pattern, we emit an error:
```
error: constant BAD_PATTERN cannot be used as pattern
--> $DIR/const_refs_to_static_fail.rs:30:9
|
LL | BAD_PATTERN => {},
| ^^^^^^^^^^^
|
= note: constants that reference mutable or external memory cannot be used as pattern
```
(If you somehow manage to build a pattern with constant `C`, you'd get the same error, but that should be impossible: we don't have a type that can be used in patterns and that has interior mutability.)
The same treatment is afforded for shared references to `extern static`, for the same reason: the const evaluation is entirely fine with it, we just can't build a pattern for it -- and when using interior mutability, this can be totally sound.
We do still not accept anything where there is an `&mut` in the final value of the const, as that should always require unsafe code and it's hard to imagine a sound use-case that would require this.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#124595 (Suggest cloning `Arc` moved into closure)
- rust-lang/rust#139594 (Simplify `ObligationCauseCode::IfExpression`)
- rust-lang/rust#141311 (make `tidy-alphabetical` use a natural sort)
- rust-lang/rust#141648 ([rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion)
- rust-lang/rust#142285 (tests: Do not run afoul of asm.validity.non-exhaustive in input-stats)
- rust-lang/rust#142393 (Don't give APITs names with macro expansion placeholder fragments in it)
- rust-lang/rust#142884 (StableMIR: Add method to retrieve body of coroutine)
- rust-lang/rust#142981 (Make missing lifetime suggestion verbose)
r? `@ghost`
`@rustbot` modify labels: rollup
Add runtime check to avoid overwrite arg in `Diag`
## Origin PR description
At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it.
For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error
```
arg `instance`already exists.
```
This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure:
1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~
2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~
## Final Decision
After trying and discussing, we made a final decision.
For `#[derive(Subdiagnostic)]`, This PR made two changes:
1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`.
2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
Add DesugaringKind::FormatLiteral
Implements `DesugaringKind::FormatLiteral` to mark the FormatArgs desugaring of format literals. The main use for this is to stop yapping about about formatting parameters if we're not anywhere near a format literal. The other use case is to fix suggestions such as https://github.com/rust-lang/rust/issues/141350. It might also be useful for new or existing diagnostics that check whether they're in a format-like macro.
cc `@xizheyin` `@fmease`
Merge unboxed trait object error suggestion into regular dyn incompat error
Another hir-walker removed from the well-formed queries. This error was always a duplicate of another, but it was able to provide more information because it could invoke `is_dyn_compatible` without worrying about cycle errors. That's also the reason we can't put the error directly into hir_ty_lowering when lowering a `dyn Trait` within an associated item signature. So instead I packed it into the error handling of wf obligation checking.
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
`nominal_obligations` calls `predicates_of` on a `Sized` obligation,
effectively elaborating the trait and making the well-formedness checking
machinery do a bunch of extra work checking a `MetaSized` obligation is
well-formed, but given that both `Sized` and `MetaSized` are built-ins,
if `Sized` is otherwise well-formed, so `MetaSized` will be.
As a performance optimization, skip elaborating the supertraits of
`Sized`, and if a `MetaSized` obligation is being checked, then look for
a `Sized` predicate in the parameter environment. This makes the
`ParamEnv` smaller which should improve compiler performance as it avoids
all the iteration over the larger `ParamEnv`.
When printing impl headers in a diagnostic, the compiler has to account
for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized`
bounds.
Like `Sized` diagnostics, sorting `MetaSized` and `PointeeSized`
diagnostics last prevents earlier more useful diagnostics from being
skipped because there has already been error tainting.
Given the necessary additions of bounds to these traits and their impls
in the standard library, it is necessary to add `MetaSized` bounds to
the obligation which is proven as part of checking for dyn
dispatchability.
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of
`Sized` and initially implement it on everything that currently
implements `Sized` to isolate any changes that simply adding the
traits introduces.
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
builtin dyn impl no guide inference
cc https://github.com/rust-lang/rust/pull/141347
we can already slightly restrict this behavior in the old solver, so why not do so. Needs crater and an FCP.
r? `@compiler-errors`
