This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes#47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
Introduce UnpackedKind
This adds an `UnpackedKind` type as a typesafe counterpart to `Kind`. This should make future changes to kinds (such as const generics!) more resilient, as the type-checker will be able to catch more potential issues.
r? @eddyb
cc @yodaldevoid
Allow for instantiating statics from upstream crates
This PR makes the infrastructure around translating statics a bit more flexible so that it can also instantiate statics from upstream crates if the need arises. This is preparatory work for a MIR-only RLIBs prototype, where the instantiation of a `static` may be deferred until a leaf crate.
r? @eddyb (feel free to assign to someone else if you're busy)
rustc_mir: handle all aggregate kinds in, and always run, the deaggregator.
This helps with removing`Rvalue::Aggregate` from the MIR, and with enabling more optimizations.
r? @nikomatsakis
This adds an `UnpackedKind` type as a typesafe counterpart to `Kind`. This should make future changes to kinds (such as const generics!) more resilient, as the type-checker should catch more potential issues.
You can now choose between the following:
- `#[unwind(allowed)]`
- `#[unwind(aborts)]`
Per rust-lang/rust#48251, the default is `#[unwind(allowed)]`, though
I think we should change this eventually.
Don't promote to 'static the result of dereferences.
This is a **breaking change**, removing copies out of dereferences from rvalue-to-`'static` promotion.
With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a `static`) or even if it can be interpreted (e.g. integer pointers).
One alternative to this ban is defining at least *some* of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion.
**EDIT**: The other *may seem* to be to add some analysis which whitelists references-to-constant-values and assume any values produced by arbitrary computation to not be safe to promote dereferences thereof - but that means producing a reference from an associated constant or `const fn` would necessarily obscure it, and in the former case, this could still impact code that runs on stable today. What we do today to track "references to statics" only works because we restrict taking a reference to a `static` at all to other `static`s (which, again, are currently limited in that they can't be read at compile-time) and to runtime-only `fn`s (*not* `const fn`s).
I'm primarily opening this PR with a conservative first approximation (e.g. `&(*r).a` is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering.
r? @nikomatsakis
