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.)
macros: hygienize use of `core`/`std` in builtin macros
Today, if a builtin macro wants to access an item from `core` or `std` (depending `#![no_std]`), it generates `::core::path::to::item` or `::std::path::to::item` respectively (c.f. `fn std_path()` in `libsyntax/ext/base.rs`).
This PR refactors the builtin macros to instead always emit `$crate::path::to::item` here. That is, the def site of builtin macros is taken to be in `extern crate core;` or `extern crate std;`. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of `$crate`.
r? @nrc
Record all imports (`use`, `extern crate`) in the crate metadata
This PR adds non-`pub` `use` and `extern crate` imports in the crate metadata since hygienic macros invoked in other crates may use them. We already include all other non-`pub` items in the crate metadata. This improves import suggestions in some cases.
Fixes#42337.
r? @nrc
Implement impl Trait lifetime elision
Fixes#43396.
There's one weird ICE in the interaction with argument-position `impl Trait`. I'm still debugging it-- I've left a test for it commented out with a FIXME.
Also included a FIXME to ensure that `impl Trait` traits are caught under the lint in https://github.com/rust-lang/rust/issues/45992.
r? @nikomatsakis
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.
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.
