Universes
This PR transitions the compiler to use **universes** instead of the **leak-check**. It is marked as [WIP] for a few reasons:
- The diagnostics at present are terrible =)
- This changes the behavior of coherence, regressing some things that used to compile
The goals of this PR at present are:
- To start getting some eyes on the code
- To do a crater run
- To see the full travis results (due to https://github.com/rust-lang/rust/issues/52452, I am not able to run the full test suite locally anymore at present)
The first few commits in the PR are changing how `evaluate` treats regions. We now track whether region comparisons occurred, reverting the "staticized" query approach that @arielb1 put in. The problem with "staticized" queries is that it relied on the leak-check to get higher-ranked things correct, and we are removing the leak-check in this PR series, so that caused problems.
You can see at the end a collection of test updates. Mostly we behave the same but with atrocious diagnostics, but there are a number of cases where we used to error and now no longer do, as well as single case where we used to **not** error but we now do (the coherence-subtyping change).
(Note: it would be possible to do a version of leak-check that propagates universe information and recover the old behavior. I am reluctant to do so because I'd like to leave us room to get more precise -- e.g., I want to eventually handle things like `exists<'a> { for<'b> { if ('a: 'b) { 'a: 'b } } }` which presently the leak-check cannot cope with etc. Also because it seems more consistent to me: most folks I've talked to expect the new behavior and are surprised to learn that binding sites were so significant before when it comes to coherence. One question is, though, to what extent are people relying on this in the wild?)
When we coerce `dyn Foo` to `dyn Bar`, that is OK as long as `Foo` is
usable in all contexts where `Bar` is usable (hence using the source
must be a subtype of the target).
This is needed for the universe-based code to handle
`old-lub-glb-object`; that test used to work sort of by accident
before with the old code.
Previously, evaluation ignored outlives relationships. Since we using
evaluation to skip the "normal" trait selection (which enforces
outlives relationships) this led to incorrect results in some cases.
Improve type mismatch error messages
Closes#56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
NLL: User type annotations refactor, associated constant patterns and ref bindings.
Fixes#55511 and Fixes#55401. Contributes to #54943.
This PR performs a large refactoring on user type annotations, checks user type annotations for associated constants in patterns and that user type annotations for `ref` bindings are respected.
r? @nikomatsakis
resolve: Simplify treatment of ambiguity errors
If we have a glob conflict like this
```rust
mod m1 { struct S; }
mod m2 { struct S; }
use m1::*;
use m2::*;
```
we treat it as a special "ambiguity item" that's not an error by itself, but produces an error when actually used.
```rust
use m1::*; // primary
use m2::*; // secondary
=>
ambiguity S(m1::S, m2::S);
```
Ambiguity items were *sometimes* treated as their primary items for error recovery, but pretty irregularly.
After this PR they are always treated as their primary items, except that
- If an ambiguity item is marked as used, then it still produces an error.
- Ambiguity items are still filtered away when exported to other crates (which is also a use in some sense).
privacy: Use common `DefId` visiting infrastructure for all privacy visitors
One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them.
This is the case because visibilities and reachabilities are attached to `DefId`s.
Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard".
This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since https://github.com/rust-lang/rust/pull/32674#discussion_r58291608 - factoring out the common visiting logic!
Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`).
A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in https://github.com/rust-lang/rust/pull/46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes https://github.com/rust-lang/rust/pull/56837#discussion_r241962239 in particular.
Also this will help with implementing https://github.com/rust-lang/rust/issues/48054.
This commit buffers the errors output by the `rustc_dump_user_substs`
attribute so that they can be output in order of span and would
therefore be consistent.
This commit stops well-formedness checking applying to unreachable code
and therefore stops some of the ICEs that the intended solution taken by
this PR causes.
By disabling these checks, we can land the other fixes and larger
refactors that this PR includes.
This commit moves well-formedness check for the
`UserTypeAnnotation::Ty(..)` case from always running to only when the
code is reachable. This solves the ICE that resulted from
`src/test/ui/issue-54943-1.rs` (a minimal repro of `dropck-eyepatch`
run-pass tests that failed).
The main well-formedness check that was intended to be run despite
unreachable code still is, that being the
`UserTypeAnnotation::TypeOf(..)` case. Before this PR, the other case
wasn't being checked at all.
It is possible to fix this ICE while still always checking
well-formedness for the `UserTypeAnnotation::Ty(..)` case but that
solution will ICE in unreachable code for that case, the diff for
that change [can be found here](0).
[0]: https://gist.github.com/davidtwco/f9751ffd9c0508f7251c0f17adc3af53
This commit adds support for user type annotations in variables declared
using `ref` bindings. When a variable declared using a `ref` binding,
then the `LocalDecl` has the type `&T` where the `&` was introduced by
the `ref` binding but the canonicalized type annotation has only a
`T` since the reference is implicit with the `ref` binding.
Therefore, to support type annotations, the canonicalized type
annotation either needs wrapped in a reference, or the `LocalDecl` type
must have a wrapped reference removed for comparison. It is easier to
remove the outer reference from the `LocalDecl` for the purpose of
comparison, so that is the approach this commit takes.
This commit uses the map introduced by the previous commit to ensure
that types are always checked for well-formedness by the NLL type check.
Previously, without the map introduced by the previous commit, types
would not be checked for well-formedness if the `AscribeUserType`
statement that would trigger that check was removed as unreachable code.
