internal: Give rustfmt jobs a separate thread
Some light testing suggests that this fixes the waiting on formatting popup in vscode when the project is still building (which is usually the way for me to encounter it, as r-a is either waiting or getting little resources causing the tasks to block formatting)
fix: derive source scope from syntax node to be transformed
Fixes#14534
When we use `PathTransform` for associated items of a trait, we have been feeding `SemanticsScope` for the trait definition to it as source scope. `PathTransform` uses the source scope to resolve paths in associated items to find which path to transform. In the course of path resolution, the scope is responsible for lowering `ast::MacroType`s (because they can be written within a path) using `AstIdMap` for the scope's `HirFileId`.
The problem here is that when an associated item is generated by a macro, the scope for the trait is different from the scope for that associated item. The former can only resolve the top-level macros within the trait definition but not the macro calls generated by those top-level macros. We need the latter to resolve such nested macros.
This PR makes sure that we pass `SemanticsScope` for each associated item we're applying path transformation to.
Properly format documentation for `SignatureHelpRequest`s
Properly formats function documentation instead of returning it raw when responding to `SignatureHelpRequest`s.
I added a test in `crates/rust-analyzer/tests/slow-tests/main.rs` -- not sure if this is the best location given the relevant code is in `crates/rust-analyzer` or if it's possible to test in a less heavyweight manner.
Closes#14958
fix: implemeted lifetime transformation fot assits
A part of https://github.com/rust-lang/rust-analyzer/issues/13363
I expect to implement transformation of const params in a separate PR
Other assists and a completion affected:
- `generate_function` currently just ignores lifetimes and, consequently, is not affected
- `inline_call` and `replace_derive_with...` don't seem to need lifetime transformation
- `trait_impl` (a completion) is fixed and tested
autopublish: Offset version number
The workflow is currently failing because it's trying to publish 0.0.16, while the last version published was 0.0.149.
Add span to group.
This appears to fix#14959, but I've never contributed to rust-analyzer before and there were some things that confused me:
- I had to add the `fn byte_range` method to get it to build. This was added to rust in [April](https://github.com/rust-lang/rust/pull/109002), so I don't understand why it wasn't needed until now
- When testing, I ran into the fact that rust recently updated its `METADATA_VERSION`, so I had to test this with nightly-2023-05-20. But then I noticed that rust has its own copy of `rust-analyzer`, and the metadata version bump has already been [handled there](60e95e76d0). So I guess I don't really understand the relationship between the code there and the code here.
internal: Migrate some assists to use the structured snippet API
Migrates the following assists:
- `add_missing_impl_members`
- `extract_type_alias`
As an additional requirement, these assists are also migrated to use the mutable AST API, since otherwise there would be overlapping `Indel` spans
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.
