Store static initializers in metadata instead of the MIR of statics.
This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better.
The issue is that
```rust
static mut FOO: &mut u32 = &mut 42;
static mut BAR = unsafe { FOO };
```
gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo.
Fixes https://github.com/rust-lang/rust/issues/61345
## Why is this being done?
In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).
Instead we re-use the static's alloc id within the interpreter for its initializer to refer to the `Allocation` that only exists within the interpreter.
Rollup of 10 pull requests
Successful merges:
- #111106 (Add known issue of let binding to format_args doc)
- #118749 (Make contributing to windows bindings easier)
- #120982 (Add APIs for fetching foreign items )
- #121022 (rustdoc: cross-crate re-exports: correctly render late-bound params in source order even if early-bound params are present)
- #121082 (Clarified docs on non-atomic oprations on owned/mut refs to atomics)
- #121084 (Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`)
- #121098 (Remove unnecessary else block from `thread_local!` expanded code)
- #121105 (Do not report overflow errors on ConstArgHasType goals)
- #121116 (Reinstate some delayed bugs.)
- #121122 (Enforce coroutine-closure layouts are identical)
r? `@ghost`
`@rustbot` modify labels: rollup
Enforce coroutine-closure layouts are identical
Enforce that for an async closure, the by-ref and by-move coroutine layouts are identical. This is just a sanity check to make sure that optimizations aren't doing anything fishy.
r? oli-obk
Reinstate some delayed bugs.
These were changed to `has_errors` assertions in #121071 because that seemed reasonable, but evidently not.
Fixes#121103.
Fixes#121108.
Do not report overflow errors on ConstArgHasType goals
This is 10% of a fix for #121090, since it at least means that we no longer mention the `ConstArgHasType` goal as the cause for the overflow. Instead, now we mention:
```
overflow evaluating the requirement `{closure@$DIR/overflow-during-mono.rs:13:41: 13:44}: Sized`
```
which is not much better, but slightly.
r? oli-obk
Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`
oversight from https://github.com/rust-lang/rust/pull/119136
Not actually an issue, because all uses of `tcx.create_def` were in the resolver, which is `eval_always`, but still good to harden against future uses of `create_def`
cc `@petrochenkov` `@WaffleLapkin`
Continue compilation after check_mod_type_wf errors
The ICEs fixed here were probably reachable through const eval gymnastics before, but now they are easily reachable without that, too.
The new errors are often bugfixes, where useful errors were missing, because they were reported after the early abort. In other cases sometimes they are just duplication of already emitted errors, which won't be user-visible due to deduplication.
fixes https://github.com/rust-lang/rust/issues/120860
Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`
oversight from https://github.com/rust-lang/rust/pull/119136
Not actually an issue, because all uses of `tcx.create_def` were in the resolver, which is `eval_always`, but still good to harden against future uses of `create_def`
cc `@petrochenkov` `@WaffleLapkin`
Extend documentation for `Ty::to_opt_closure_kind` method
This API was... surprising to use. With a little extra documentation, the weirdness can be reduced quite a lot. :)
r? `@compiler-errors`
Use fewer delayed bugs.
For some cases where it's clear that an error has already occurred, e.g.:
- there's a comment stating exactly that, or
- things like HIR lowering, where we are lowering an error kind
The commit also tweaks some comments around delayed bug sites.
r? `@oli-obk`
Optimize `delayed_bug` handling.
Once we have emitted at least one error, delayed bugs won't be used. So we can (a) we can (a) discard any existing delayed bugs, and (b) stop recording any new delayed bugs.
This eliminates a longstanding `FIXME` comment. There should be no soundness issues because it's not possible to un-emit an error.
r? `@oli-obk`
Fix suggestion span for `?Sized` when param type has default
Fixes#120878
Diagnostic suggests adding `: ?Sized` in an incorrect place if a type parameter default is present
r? `@fmease`
Be less confident when `dyn` suggestion is not checked for object safety
#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in #116434
r? ```@fmease```
Uplift `TypeVisitableExt` into `rustc_type_ir`
This uplifts `TypeVisitableExt` into `rustc_type_ir` so it can be used in an interner-agnostic way. It also moves some `TypeSuperVisitable` bounds onto `Interner` since we don't expect to support libraries that have types which aren't foldable by default.
This restores a couple of asserts in the canonicalizer code we uplifted, and also makes it so that we can use type-flags-based helpers in the solver code, which I'm interested in uplifting.
r? lcnr
For some cases where it's clear that an error has already occurred,
e.g.:
- there's a comment stating exactly that, or
- things like HIR lowering, where we are lowering an error kind
The commit also tweaks some comments around delayed bug sites.
Fully stop using the HIR in trait impl checks
At least I hope I found all happy path usages. I'll need to check if I can figure out a way to make queries declare that they don't access the HIR except in error paths
`cargo update`
Run `cargo update`, with some pinning and fixes necessitated by that. This *should* unblock #112865
There's a couple of places where I only pinned a dependency in one location - this seems like a bit of a hack, but better than duplicating the FIXME across all `Cargo.toml` where a dependency is introduced.
cc `@Nilstrieb`
Ignore own item bounds in parent alias types in `for_each_item_bound`
Fixes#120912
I want to get a vibe check on this approach, which is very obviously a hack, but I believe something that is forwards-compatible with a more thorough solution and "good enough for now".
The problem here is that for a really deep rigid associated type, we are now repeatedly considering unrelated item bounds from the parent alias types, meaning we're doing a *lot* of extra work in the MIR inliner for deeply substituted rigid projections.
This feels intimately related to #107614. In that PR, we split *supertrait* bounds (bound which share the same `Self` type as the predicate which is being elaborated) and *implied* bounds (anything that is implied by elaborating the predicate).
The problem here is related to the fact that we don't maintain the split between these two for `item_bounds`. If we did, then when recursing into a parent alias type, we'd want to consider only the bounds that are given by [`PredicateFilter::All`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly) **except** those given by [`PredicateFilter::SelfOnly`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly).
Do not assemble candidates for default impls
There is no reason (as far as I can tell?) that we should assemble an impl candidate for a default impl. This candidate itself does not prove that the impl holds, and any time that it *does* hold, there will be a more specializing non-default impl that also is assembled.
This is because `default impl<T> Foo for T {}` actually expands to `impl<T> Foo for T where T: Foo {}`. The only way to satisfy that where clause (without coinduction) is via *another* implementation that does hold -- precisely an impl that specializes it.
This should fix the specialization related regressions for #116494. That should lead to one root crate regression that doesn't have to do with specialization, which I think we can regress.
r? lcnr cc ``@rust-lang/types``
cc #31844
Check normalized call signature for WF in mir typeck
Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls.
Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here.
**See** boxy's detailed and useful explanation comment which explains this in more detail: https://github.com/rust-lang/rust/issues/114936#issuecomment-1710388741Fixes#114936Fixes#118876
r? types
cc ``@BoxyUwU`` ``@lcnr``
Once we have emitted at least one error, delayed bugs won't be used. So
we can (a) we can (a) discard any existing delayed bugs, and (b) stop
recording any new delayed bugs.
This eliminates a longstanding `FIXME` comment. There should be no
soundness issues because it's not possible to un-emit an error.
