internal: Record file dependencies in crate graph construction
Should fix the bug mentioned in https://github.com/rust-lang/rust-analyzer/issues/8623 where removing a crate root file will panic. I'm not too happy with the way this is done here but I can't think of a better way right now.
Deduplicate tuple indices for completion
Follow-up to #15026
A tuple struct may dereference to a primitive tuple (though unusual, which is why I previously overlooked this case). We should not show the same tuple index in completion in such cases.
Deduplication of indices among multiple tuple structs is already handled in the previous PR.
fix: deduplicate fields and types in completion
Fixes#15024
- `hir_ty::autoderef()` (which is only meant to be used outside `hir-ty`) now deduplicates types and completely resolves inference variables within.
- field completion now deduplicates fields of the same name and only picks such field of the first type in the deref chain.
Lower const params with a bad id
cc #7434
This PR adds an `InTypeConstId` which is a `DefWithBodyId` and lower const generic parameters into bodies using it, and evaluate them with the mir interpreter. I think this is the last unimplemented const generic feature relative to rustc stable.
But there is a problem: The id used in the `InTypeConstId` is the raw `FileAstId`, which changes frequently. So these ids and their bodies will be invalidated very frequently, which is bad for incremental analysis.
Due this problem, I disabled lowering for local crates (in library crate the id is stable since files won't be changed). This might be overreacting (const generic expressions are usually small, maybe it would be better enabled with bad performance than disabled) but it makes motivation for doing it in the correct way, and it splits the potential panic and breakages that usually comes with const generic PRs in two steps.
Other than the id, I think (at least I hope) other parts are in the right direction.
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.
