Infer return type for async function in `generate_function`
Part of #10122
In `generate_function` assist, when we infer the return type of async function we're generating, we should retrieve the type of parent await expression rather than the call expression itself.
fix: only generate trait bound for associated types in field types
Given the following definitions:
```rust
trait Trait {
type A;
type B;
type C;
}
#[derive(Clone)]
struct S<T: Trait>
where
T::A: Send,
{
qualified: <T as Trait>::B,
shorthand: T::C,
}
```
we currently expand the derive macro to:
```rust
impl<T> Clone for S<T>
where
T: Trait + Clone,
T::A: Clone,
T::B: Clone,
T::C: Clone,
{ /* ... */ }
```
This does not match how rustc expands it. Specifically, `Clone` bounds for `T::A` and `T::B` should not be generated.
The criteria for associated types to get bound seem to be 1) the associated type appears as part of field types AND 2) it's written in the shorthand form. I have no idea why rustc doesn't consider qualified associated types (there's even a comment that suggests they should be considered; see rust-lang/rust#50730), but it's important to follow rustc.
Emit `'_` for lifetime generics in `HirDisplay`
This makes the generated code not linted by `rust_2018_idioms` lint. But that is an allow by default lint, so should we do this? Maybe we should only do this for `DisplayTarget::SourceCode`?
fix: consider outer binders when folding captured items' type
Fixes#14966
Basically, the crash is caused by us producing a broken type and passing it to chalk: `&dyn for<type> [for<> Implemented(^1.0: A<^0.0>)]` (notice the innermost bound var `^0.0` has no corresponding binder). It's created in `CapturedItemWithoutTy::with_ty()`, which didn't consider outer binders when folding types to replace placeholders with bound variables.
The fix is one-liner, but I've also refactored the surrounding code a little.
- use `DefWithBodyId::as_generic_def_id()`
- add comments on `InferenceResult` invariant
- move local helper function to bottom to comply with style guide
Revert "Add mandatory panic contexts to all threadpool tasks"
Reverts rust-lang/rust-analyzer#14965
This won't quite work actually given the use of `catch_unwind` in some of these
Add mandatory panic contexts to all threadpool tasks
the diagnostics task is panicking I think, but without this you can't really tell because the stack trace ends in a generic iterator fold call instead of something specific.
Fix drop scopes problems in mir
Fix false positives of `need-mut` emerged from #14955
There are still 5 `need-mut` false positives on self, all related to `izip!` macro hygenic issue. I will try to do something about that before monday release.