extend NLL with preliminary support for free regions on functions
This PR extends https://github.com/rust-lang/rust/pull/45538 with support for free regions. This is pretty preliminary and will no doubt want to change in various ways, particularly as we add support for closures, but it's enough to get the basic idea in place:
- We now create specific regions to represent each named lifetime declared on the function.
- Region values can contain references to these regions (represented for now as a `BTreeSet<RegionIndex>`).
- If we wind up trying to infer that `'a: 'b` must hold, but no such relationship was declared, we report an error.
It also does a number of drive-by refactorings.
r? @arielb1
cc @spastorino
RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute
This work-in-progress pull request contains my changes to implement [RFC 2008](https://github.com/rust-lang/rfcs/pull/2008). The related tracking issue is #44109.
As of writing, enum-related functionality is not included and there are some issues related to tuple/unit structs. Enum related tests are currently ignored.
WIP PR requested by @nikomatsakis [in Gitter](https://gitter.im/rust-impl-period/WG-compiler-middle?at=59e90e6297cedeb0482ade3e).
add TerminatorKind::FalseEdges and use it in matches
impl #45184 and fixes#45043 right way.
False edges unexpectedly affects uninitialized variables analysis in MIR borrowck.
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
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
This commit makes librustc_passes::consts::CheckCrateVisitor properly
mark expressions as promotable if they reference a static, as it's
perfectly fine for one static to reference another. It fixes a
regression that prevented a temporary rvalue from referencing a static
if it was itself declared within a static.
Prior to commit https://github.com/rust-lang/rust/commit/b8c05fe90bc,
`region::ScopeTree` would only register a 'terminating scope' for function
bodies. Thus, while rvalues in a static that referenced a static would be marked
unpromotable, the lack of enclosing scope would cause
mem_categorization::MemCategorizationContext::cat_rvalue_node
to compute a 'temporary scope' of `ReStatic`. Since this had the same
effect as explicitly selecting a scope of `ReStatic`
due to the rvalue being marked by CheckCrateVisitor as promotable,
no issue occurred.
However, commit https://github.com/rust-lang/rust/commit/b8c05fe90bc
made ScopeTree unconditionally register a 'terminating scope'
Since mem_categorization would now compute a non-static 'temporary scope', the
aforementioned rvalues would be erroneously marked as living for too
short a time.
By fixing the behavior of CheckCrateVisitor, this commit avoids changing
mem_categorization's behavior, while ensuring that temporary values in
statics are still allowed to reference other statics.
Fixes issue #44373
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.
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
