Document the sysroot field in JsonProject
rust-analyzer supports both `sysroot` and `sysroot_src` in `rust-project.json`. Document `sysroot` and show example values for both fields.
internal: Lazy eager macros
This PR makes eager macros less eager. We now only eagerly expand the input of them, while the actual expansion of the macro itself now happens like other lazy macros.
This change allows unifying a lot of macro handling between the two now, most of the special casing now happens for `include!` specifically as it is a very unique macro (by having two inputs that come from differing files).
Fixes https://github.com/rust-lang/rust-analyzer/issues/14841
Fixes https://github.com/rust-lang/rust-analyzer/issues/14996
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
