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.
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:
![screenshot from 2016-05-25 14-02-42](https://cloud.githubusercontent.com/assets/332036/15539231/84b018cc-2281-11e6-9666-1063655931f4.png)
There are degenerate cases for enum tuple variants with lots of fields:
![screenshot from 2016-05-25 14-01-00](https://cloud.githubusercontent.com/assets/332036/15539260/91e537ca-2281-11e6-8bf1-a3d6b2e78f65.png)
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
Added examples/docs to split in str.rs
Added documentation clarifying the behavior of split when used with the empty string and contiguous separators. Addresses issue [33882](https://github.com/rust-lang/rust/issues/33882). This is my first time contributing to rust, so forgive me if I'm skipping any of the contribution steps.
Fixes#33882
Separate bindings from other patterns in HIR
Now when name resolution is done on AST, we can avoid dumping everything that looks like an identifier into `PatKind::Ident` in HIR.
`hir::PatKind::Ident` is removed, fresh bindings are now called `hir::PatKind::Binding`, everything else goes to `hir::PatKind::Path`.
I intend to do something with `PatKind::Path`/`PatKind::QPath` as well using resolution results, but it requires some audit and maybe some deeper refactoring of relevant resolution/type checking code to do it properly.
I'm submitting this part of the patch earlier to notify interested parties that I'm working on this.
cc @jseyfried
r? @eddyb
antlr grammar verification script now compiles under latest nightly
This is kind of a moving target, since none of libsyntax is stable, but at least this compiles for the time being.
save-analysis: be a bit more defensive with field sub-expressions
Prevents an ice with `(...).f` since the sub-expression is in the AST but not the HIR.
We could actually do better in this specific case, but it doesn't seem worth it.
Prevent overflows by increasing ring buffer size
Please note that this change is just done to prevent
issues as currently seen by syntex_syntax in future.
See https://github.com/serde-rs/syntex/pull/47 for details.
As shown in https://github.com/serde-rs/syntex/issues/33,
complex code can easily overflow the ring-buffer and
cause an assertion error.