To handle the general case, we include a vector of def-ids, so that we
can account for things like `(Foo, Bar)` which references both `Foo` and
`Bar`. This means it is not Copy, so re-jigger some APIs to use
borrowing more intelligently.
Currently, when projecting out of a higher-ranked where-clause, we
instantiate all higher-ranked regions with lifetime variables. This is
unnecessary since the language rules ought to guarantee (modulo #32330)
that each of those higher-ranked regions is equated with some regions
from the input types. This routine figures out what those regions are
and just uses them. Also, since #32330 is not fully fixed, it detects
when we may have unconstrained variables and indicates that in its
return value.
We used to make region->region edges part of the verify set, but this
change stores them like other edges, as a full-fledged constraint.
Besides making the code somewhat cleaner, this allows them to be more
easily dropped as part of `pop_skolemized`. This change also refactors
the code a bit to remove some intermediate data structures that are no
longer particular useful (e.g., VarValue).
When we do a "HR subtype" check, we replace all late-bound regions (LBR)
in the subtype with fresh variables, and skolemize the late-bound
regions in the supertype. If those skolemized regions from the supertype
wind up being super-regions (directly or indirectly) of either
- another skolemized region; or,
- some region that pre-exists the HR subtype check
- e.g., a region variable that is not one of those created
to represent bound regions in the subtype
then the subtype check fails.
What will change when we fix#32330 is that some of the LBR in the
subtype may become early-bound. In that case, they would no longer be in
the "permitted set" of variables that can be related to a skolemized
type.
So the foundation for this warning is to collect variables that we found
to be related to a skolemized type. For each of them, we have a
`BoundRegion` which carries a `Issue32330` flag. We check whether any of
those flags indicate that this variable was created from a lifetime
that will change from late- to early-bound. If so, we issue a warning
indicating that the results of compilation may change.
This is imperfect, since there are other kinds of code that will not
compile once #32330 is fixed. However, it fixes the errors observed in
practice on crater runs.
This indicates whether this `BoundRegion` will change from late to early
bound when issue 32330 is fixed. It also indicates the function on
which the lifetime is declared.
Currently, we consider region subtyping a failure
if a skolemized lifetime is relatable to any
other lifetime in any way at all. But a more precise
formulation is to say that a skolemized lifetime:
- must not have any *incoming* edges in the region graph
- only has *outgoing* edges to nodes that are `'static`
To enforce the latter requirement, we add edges from `'static -> 'x` for
each lifetime '`x' reachable from a skolemized region.
We now have to add a new `pop_skolemized` routine to do cleanup.
Whereas before if there were *any* edges relating to a skolemized
region, we would return `Err` and hence rollback the transaction, we now
tolerate some edges and return `Ok`. Therefore, the `pop_skolemized`
routine runs and cleans up those edges.
mk: Prepare for a new stage0 compiler
This commit prepares the source for a new stage0 compiler, the 1.10.0 beta
compiler. These artifacts are hot off the bots and should be ready to go.
Be sure to not use the old build cache for the bootstrap build system nor the
old caches of the compiler/cargo extractions (in case something went wrong).
Closes#33986
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
This is in the matter of issue #33394.
In 1a374b8, (pr #33046) fixed the error reporting of a specific
case, but the change that was introduced did not make sure that
`record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes
that were committed in 1a374b8.
This commit fixes issue #33293.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
print enum variant fields in docs
Right now we are repeating enum variants at the top, because the fields aren't shown with the actual docs. It's very annoying to have to scroll up and down to have both docs and field info. For struct variants we already list the fields.
enum docs look like this after this PR:
There are degenerate cases for enum tuple variants with lots of fields:
I was thinking that we could move the docs below the variant (slightly indented) or list the variant fields vertically instead of horizontally
r? @steveklabnik
