Fixes rust-lang#60021 and rust-lang#72415.

Fixes rust-lang#69446

When we encounter a region error involving an `FnMut` closure, we
display a specialized error message. However, we currently do not
tell the user which upvar was captured. This makes it difficult to
determine the cause of the error, especially when the closure is large.

This commit records marks constraints involving closure upvars
with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame'
a `ConstraintCategory::Return`, we additionall store
the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in
the path.

When generating an error message, we point to relevant spans if we have
closure upvar information available. We further customize the message if
an `async` closure is being returned, to make it clear that the captured
variable is being returned indirectly.

Also, implement this query for the local crate, not just foreign crates.

It was applied to a `use` item, not to the module

This commit adds a `Closure` variant to `NonStructuralMatchTy` in
`structural_match`, fixing an ICE which can occur when
`impl_trait_in_bindings` is used with constants.

Signed-off-by: David Wood <[email protected]>

The existing error documentation did not show how to use a child module's functions if the types used in those functions are private. These are some other places this problem has popped up that did not present a solution (these are from before the solution existed, 2016-2017. The solution was released in the Rust 2018 edition. However these were the places I was pointed to when I encountered the problem myself):
rust-lang#30905
https://stackoverflow.com/questions/39334430/how-to-reference-private-types-from-public-functions-in-private-modules/62374958#62374958

…p-elab, r=oli-obk

Check for live drops in constants after drop elaboration

Resolves rust-lang#66753.

This PR splits the MIR "optimization" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking, which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate.

As a result, we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths, however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local.

r? @oli-obk

… r=nikomatsakis

Explain move errors that occur due to method calls involving `self`

When calling a method that takes `self` (e.g. `vec.into_iter()`), the method receiver is moved out of. If the method receiver is used again, a move error will be emitted::

```rust
fn main() {
    let a = vec![true];
    a.into_iter();
    a;
}
```

emits

```
error[E0382]: use of moved value: `a`
 --> src/main.rs:4:5
  |
2 |     let a = vec![true];
  |         - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 |     a.into_iter();
  |     - value moved here
4 |     a;
  |     ^ value used here after move
```

However, the error message doesn't make it clear that the move is caused by the call to `into_iter`.

This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method::

```
error[E0382]: use of moved value: `a`
   --> vec.rs:4:5
    |
2   |     let a = vec![true];
    |         - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3   |     a.into_iter();
    |     ------------- value moved due to this method call
4   |     a;
    |     ^ value used here after move
    |
note: this function takes `self`, which moves the receiver
   --> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5
    |
239 |     fn into_iter(self) -> Self::IntoIter;
```

TODO:

- [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods
- [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`)
- [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.

…rent-impl, r=estebank

Fix trait alias inherent impl resolution

Fixes rust-lang#60021 and fixes rust-lang#72415.

Obviously, the fix was very easy, but getting started with the testing and debugging rust compiler was an interesting experience. Now I can cross it off my bucket list!

Stabilize vec::Drain::as_slice

and add `AsRef<[T]> for Drain<'_, T>`.

Tracking issue: rust-lang#58957. Does not stabilize `slice::IterMut::as_slice` yet. cc @cuviper
This PR proposes stabilizing just the `vec::Drain::as_slice` part of that tracking issue.

My ultimate goal here: being able to use `for<T, I: Iterator<Item=T>   AsRef<[T]>> I` to refer to `vec::IntoIter`, `vec::Drain`, and eventually `array::IntoIter`, as an approximation of the set of by-value iterators that can be "previewed" as by-ref iterators. (Actually expressing that as a trait requires GAT.)

…n, r=nikomatsakis

Display information about captured variable in `FnMut` error

Fixes rust-lang#69446

When we encounter a region error involving an `FnMut` closure, we
display a specialized error message. However, we currently do not
tell the user which upvar was captured. This makes it difficult to
determine the cause of the error, especially when the closure is large.

This commit records marks constraints involving closure upvars
with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame'
a `ConstraintCategory::Return`, we additionall store
the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in
the path.

When generating an error message, we point to relevant spans if we have
closure upvar information available. We further customize the message if
an `async` closure is being returned, to make it clear that the captured
variable is being returned indirectly.

Group `Pattern::strip_*` method together

_match.rs: fix module doc comment

It was applied to a `use` item, not to the module

Fix iterator copied() documentation example code

The documentation for copied() gives example code with variable v_cloned instead of v_copied. This seems like a copy/paste error from cloned() and it would be clearer to use v_copied.

Update E0446.md

The existing error documentation did not show how to use a child module's functions if the types used in those functions are private. These are some other places this problem has popped up that did not present a solution (these are from before the solution existed, 2016-2017. The solution was released in the Rust 2018 edition. However these were the places I was pointed to when I encountered the problem myself):
rust-lang#30905
https://stackoverflow.com/questions/39334430/how-to-reference-private-types-from-public-functions-in-private-modules/62374958#62374958

…l-match-ty-closures, r=varkor

structural_match: non-structural-match ty closures

Fixes rust-lang#73003.

This PR adds a `Closure` variant to `NonStructuralMatchTy` in `structural_match`, fixing an ICE which can occur when `impl_trait_in_bindings` is used with constants.