(The idea is that the StorageDead marks the point where the memory can
be deallocated, and the EndRegion is marking where borrows of that
memory can no longer legally exist.)
Evaluate fixed-length array length expressions lazily.
This is in preparation for polymorphic array lengths (aka `[T; T::A]`) and const generics.
We need deferred const-evaluation to break cycles when array types show up in positions which require knowing the array type to typeck the array length, e.g. the array type is in a `where` clause.
The final step - actually passing bounds in scope to array length expressions from the parent - is not done because it still produces cycles when *normalizing* `ParamEnv`s, and @nikomatsakis' in-progress lazy normalization work is needed to deal with that uniformly.
However, the changes here are still useful to unlock work on const generics, which @EpicatSupercell manifested interest in, and I might be mentoring them for that, but we need this baseline first.
r? @nikomatsakis cc @oli-obk
Allow Drop types in const's too, with #![feature(drop_types_in_const)].
Implements the remaining amendment, see #33156. cc @SergioBenitez
r? @nikomatsakis
Migrate a slew of metadata methods to queries
This PR intends to make more progress on #41417, knocking off some low-hanging fruit.
Closes#44190
cc #44137
Debugflag: -Z emit-end-regions
Skip EndRegion emission by default. Use `-Z emit-end-regions` to reenable it.
The main intent is to fix cases where `EndRegion` emission is believed to be causing excess peak memory pressure.
It may also be a welcome change to people inspecting the MIR output who find the EndRegions to be a distraction.
(In later follow-up PR's I will put in safe-guards against using the current mir-borrowck without enabling `EndRegion` emission. But I wanted this PR to be minimal, in part because we may wish to backport it to the beta channel if we find that it reduces peak memory usage significantly.)
Previously a `Symbol` was stored there, but this ended up causing hash
collisions in situations that otherwise shouldn't have a hash collision. Only
the symbol's string value was hashed, but it was possible for distinct symbols
to have the same string value, fooling various calcuations into thinking that
these paths *didn't* need disambiguating data when in fact they did!
By storing `InternedString` instead we're hopefully triggering all the exising
logic to disambiguate paths with same-name `Symbol` but actually distinct
locations.
This commit moves the calculation of the `LanguageItems` structure into a
query rather than being calculated before the `TyCtxt` exists, with the eventual
end goal of removing some `CrateStore` methods.
The main intent is to fix cases where EndRegion emission is believed
to be causing excess peak memory pressure.
It may also be a welcome change to people inspecting the MIR output
who find the EndRegions to be a distraction.
Forward-compatibly deny drops in constants if they *could* actually run.
This is part of #40036, specifically the checks for user-defined destructor invocations on locals which *may not* have been moved away, the motivating example being:
```rust
const FOO: i32 = (HasDrop {...}, 0).1;
```
The evaluation of constant MIR will continue to create `'static` slots for more locals than is necessary (if `Storage{Live,Dead}` statements are ignored), but it shouldn't be misusable.
r? @nikomatsakis
Fix destruction extent lookup during HIR -> HAIR translation
My method for finding the destruction extent, if any, from cbed41a174aad44e069bec09bf1e502591c132ae (in #39409), was buggy in that it sometimes failed to find an extent that was nonetheless present.
This fixes that, and is cleaner code to boot.
Fix#43457
rustc: Start moving toward "try_get is a bug" for incremental
This PR is an effort to burn down some of the work items on #42633. The basic change here was to leave the `try_get` function exposed but have it return a `DiagnosticBuilder` instead of a `CycleError`. This means that it should be a compiler bug to *not* handle the error as dropping a diagnostic should result in a complier panic.
After that change it was then necessary to update the compiler's callsites of `try_get` to handle the error coming out. These were handled as:
* The `sized_constraint` and `needs_drop_raw` checks take the diagnostic and defer it as a compiler bug. This was a new piece of functionality added to the error handling infrastructure, and the idea is that for both these checks a "real" compiler error should be emitted elsewhere, so it's only a bug if we don't actually emit the complier error elsewhere.
* MIR inlining was updated to just ignore the diagnostic. This is being tracked by https://github.com/rust-lang/rust/issues/43542 which sounded like it either already had some work underway or was planning to change regardless.
* The final case, `item_path`, is still sort of up for debate. At the time of this writing this PR simply removes the invocations of `try_get` there, assuming that the query will always succeed. This turns out to be true for the test suite anyway! It sounds like, though, that this logic was intended to assist in "weird" situations like `RUST_LOG` where debug implementations can trigger at any time. This PR would therefore, however, break those implementations.
I'm unfortunately sort of out of ideas on how to handle `item_path`, but other thoughts would be welcome!
Closes#42633
