[MIR-borrowck] Two phase borrows
This adds limited support for two-phase borrows as described in
http://smallcultfollowing.com/babysteps/blog/2017/03/01/nested-method-calls-via-two-phase-borrowing/
The support is off by default; you opt into it via the flag `-Z two-phase-borrows`
I have written "*limited* support" above because there are simple variants of the simple `v.push(v.len())` example that one would think should work but currently do not, such as the one documented in the test compile-fail/borrowck/two-phase-reservation-sharing-interference-2.rs
(To be clear, that test is not describing something that is unsound. It is just providing an explicit example of a limitation in the implementation given in this PR. I have ideas on how to fix, but I want to land the work that is in this PR first, so that I can stop repeatedly rebasing this branch.)
trait alias infrastructure
This will be an implementation of trait aliases (RFC 1733, #41517).
Progress so far:
- [x] Feature gate
- [x] Add to parser
- [x] `where` clauses
- [x] prohibit LHS type parameter bounds via AST validation https://github.com/rust-lang/rust/pull/45047#discussion_r143575575
- [x] Add to AST and HIR
- [x] make a separate PathSource for trait alias contexts https://github.com/rust-lang/rust/pull/45047#discussion_r143353932
- [x] Stub out enough of typeck and resolve to just barely not ICE
Postponed:
- [ ] Actually implement the alias part
- [ ] #21903
- [ ] #24010
I need some pointers on where to start with that last one. The test currently does this:
```
error[E0283]: type annotations required: cannot resolve `_: CD`
--> src/test/run-pass/trait-alias.rs:34:16
|
34 | let both = foo();
| ^^^
|
= note: required by `foo`
```
Validate miri against the HIR const evaluator
r? @eddyb
cc @alexcrichton @arielb1 @RalfJung
The interesting parts are the last few functions in `librustc_const_eval/eval.rs`
* We warn if miri produces an error while HIR const eval does not.
* We warn if miri produces a value that does not match the value produced by HIR const eval
* if miri succeeds and HIR const eval fails, nothing is emitted, but we still return the HIR error
* if both error, nothing is emitted and the HIR const eval error is returned
So there are no actual changes, except that miri is forced to produce the same values as the old const eval.
* This does **not** touch the const evaluator in trans at all. That will come in a future PR.
* This does **not** cause any code to compile that didn't compile before. That will also come in the future
It would be great if someone could start a crater run if travis passes
Since we are now checking activation points, I removed one of the
checks at the reservation point. (You can see the effect this had on
two-phase-reservation-sharing-interference-2.rs)
Also, since we now have checks at both the reservation point and the
activation point, we sometimes would observe duplicate errors (since
either one independently interferes with another mutable borrow). To
deal with this, I used a similar strategy to one used as discussed on
issue #45360: keep a set of errors reported (in this case for
reservations), and then avoid doing the checks for the corresponding
activations. (This does mean that some errors could get masked, namely
for conflicting borrows that start after the reservation but still
conflict with the activation, which is unchecked when there was an
error for the reservation. But this seems like a reasonable price to
pay.)
move `resolve_lifetimes` into a proper query
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
r? @michaelwoerister
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
We issue just one message for an erroneous glob private variant reëxport
(using the Session's one-time-diagnostics capability), but individual
(non-glob) such erroneous reëxports still get their own messages. The
suggestion to make the enum public is also one-time.
The enum variant reëxport error didn't have an associated error code
(and remedying this here is deemed out of the scope of this commit), so
we resort to the expediency of using 0 as the `DiagnosticMessageId`
value.
Adding Debug to NameResolution was helpful in development.
This resolves#46209.
Modify message for keyword as identifier name
This is a temporary solution to #46311.
The message is generic enough to cover both cases and is probably a fine enough solution to the specific problem described in the task. However, the underlying reason for this to be wrong is that `next_token_inner` returns `Lifetime` even if the token is a label. That's not simple, as the syntax for both can be quite similar and it may need to take a look to the next token to make a decision. I'm not sure I have enough knowledge about the project to be able to solve that (yet!), so I thought I'll fix the immediate problem first.
Allow feature-gate tests to live in ui/ and migrate most of the tests from compile-fail
The PR consists of three commits:
1. change tidy to allow feature-gate tests to live in ui/
2. migrate some feature gate tests to ui/ with renaming only
3. migrate some feature gate tests to ui/ with also removing `// gate-test-...` lines and renaming them to the standard `feature-gate-<feat-name>.rs` format.
Stabilize abi_sysv64
Closes#36167, stabilizing the use of the "sysv64" ABI on x64 platforms where it is not the default ABI.
FCP on this is complete in the tracking issue.
MIR borrowck: implement union-and-array-compatible semantics
Fixes#44831.
Fixes#44834.
Fixes#45537.
Fixes#45696 (by implementing DerefPure semantics, which is what we want going forward).
r? @nikomatsakis
