fix broken assertion in type_param
Nested generics (aka method generics) in trait methods don't have an
*additional* Self parameter in their own type parameter list (they have
a Self parameter in the parent generics), so don't try to check we're
correctly adjusting for it.
Fixes#46568.
r? @eddyb
This simple patch resolves#46756 (which was specifically about the case of
casts, but it would be poor form indeed to fix a reported issue without at
least a cursory attempt at answering the immortal question, "How does this bug
generalize?").
Point at var in short lived borrows instead of drop location
For RLS' sake, point at the borrow location as primary span for short lived borrows, instead of the borrow drop location.
Fix#39268.
rustc_trans: approximate ABI alignment for padding/union fillers.
Before #45225 and after this PR, unions and enums are filled with integers of size and alignment matching their alignment (e.g. `Option<u32>` becomes `[u32; 2]`) instead of mere bytes.
Also, the alignment padding between struct fields gets this treatment after this PR.
Partially helps with some reduced testcases in #46449, although it doesn't solve the bug itself.
Lifetime Resolution for Generic Associated Types
Tracking Issue: https://github.com/rust-lang/rust/issues/44265
r? @nikomatsakis
This PR implements lifetime resolution for generic associated types. 🎉
## Remaining Work Before Merge
I'm going to go do these things in the next day or so. Please let me know if you spot anything in my changes until then.
- [x] If I'm not mistaken, at least some tests should pass now. I need to go through the tests and re-enable the ones that should work by removing the appropriate `~ ERROR` comments
[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.)
In reality the currently generated MIR has at least one of the activations
in a copy that occurs before the merge. But still, good to have a test,
in anticipation of that potentially changing...
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
Point at whole method call instead of args
To avoid confusion in cases where the code is
```rust
fn foo() {}
/ foo(
| bar()
| ^^^ current diagnostics point here for arg count mismatch
| );
|_^ new diagnostic span points here
```
as this leads to confusion making people think that the diagnostic is
talking about `bar`'s arg count, not `foo`'s.
Point at `fn`s definition on arg mismatch, just like we do for closures.
Re #42855, Fix#45633.
Nested generics (aka method generics) in trait methods don't have an
*additional* Self parameter in their own type parameter list (they have
a Self parameter in the parent generics), so don't try to check we're
correctly adjusting for it.
Fixes#46568.
make MIR type checker handle a number of other cases
The existing type checker was primarily used to verify types, but was skipping over a number of details. For example, it was not checking that the predicates on functions were satisfied and so forth. This meant that the NLL region checker was not getting a lot of the constraints it needed. This PR closes those gaps. It also includes a bit of refactoring for the way that we store region values, encapsulating the bit matrix over into its own module and improving the data structures in use.
This is mostly work by @spastorino being ported over from nll-master.
r? @arielb1 or @pnkfelix
Fix visible_parent_map to choose globally minimal paths
Fix#46112: visible_parent_map construction needs a BFS over whole crate forest to get globally minimal paths.
(There are other latent bugs that were e.g. causing this test case to have weirdness like `<unnamed>` in the diagnostic output. Those bugs are not fixed here, since they are issues long-standing in the stable channel.)
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.)
