fix: Fix nav target calculation discarding file ids from differing macro upmapping
Fixes https://github.com/rust-lang/rust-analyzer/issues/14792
Turns out there was the assumption that upmapping from a macro will always end in the same root file, which is no longer the case thanks to `include!`
Add signature help for tuple patterns and expressions
~~These are somewhat wonky since their signature changes as you type depending on context but they help out nevertheless.~~ should be less wonky now with added parser and lowering recoveries
fix: Don't duplicate sysroot crates in rustc workspace
Since we handle `library` as the sysroot source directly in the rustc workspace, we now duplicate the crates there, once as sysroot and once as just plain workspace crate. This causes a variety of issues for `vec!` macros and similar that emit `$crate` tokens across crates.
Prioritize threads affected by user typing
To this end I’ve introduced a new custom thread pool type which can spawn threads using each QoS class. This way we can run latency-sensitive requests under one QoS class and everything else under another QoS class. The implementation is very similar to that of the `threadpool` crate (which is currently used by rust-analyzer) but with unused functionality stripped out.
I’ll have to rebase on master once #14859 is merged but I think everything else is alright :D
Fix edits for `convert_named_struct_to_tuple_struct`
Two fixes:
- When replacing syntax nodes, macro files weren't taken into account. Edits were simply made for `node.syntax().text_range()`, which would be wrong range when `node` is inside a macro file.
- We do ancestor node traversal for every struct name reference to find record expressions/patterns to edit, but we didn't verify that expressions/patterns do actually refer to the struct we're operating on.
Best reviewed one commit at a time.
Fixes#13780Fixes#14927
MIR episode 6
This PR separates monomorphization from interpreting, and add a monomorphization query to cache the results. Together with making layout queries returning `Arc<Layout>` instead of `Layout` (did you know that `Layout` is a 312 byte struct with a couple of vectors, so it is very costly to clone? I thought it should be very small and cheap) it makes mir interpreting an order of magnitude faster in warmed calls.
It still can't evaluate no test in the r-a repo, but all tests that I tried are hitting #7434 so I hope after that it will become able to interpret some real world test.
Previously we didn't verify that record expressions/patterns that were
found did actually point to the struct we're operating on. Moreover,
when that record expressions/patterns had missing child nodes, we would
continue traversing their ancestor nodes.
This code replaces the thread pool implementation we were using
previously (from the `threadpool` crate). By making the thread pool
aware of QoS, each job spawned on the thread pool can have a different
QoS class.
This commit also replaces every QoS class used previously with Default
as a temporary measure so that each usage can be chosen deliberately.
Fix rustup installation description
While going through the process of installing rust-analyzer to use with Neovim, I noticed that the instructions for installing with rustup are incorrect now that [issue #2411](https://github.com/rust-lang/rustup/issues/2411) has been closed. Now when rust-analyzer is installed using rustup, it is installed in ~/.cargo/bin and a symlink or some other workaround is no longer needed. I have updated the documentation accordingly.
fix: add a toggle to disable the dependency explorer
For common uses of non-Cargo build systems with rust-analyzer, the dependency view isn't particularly helpful because there isn't a Cargo.toml present for dependencies or the dependencies are part of the current workspace.
Speaking from the perspective of a user of `rust-project.json`, I'd prefer to have this feature disabled until I can add a field to `Crate` that defines the location of a build file (e.g., a `BUCK`) file, which would allow for removing the "search for a Cargo.toml in parent directories of a crate root" behavior that exists in a few places (I've opened [an issue](https://github.com/rust-lang/cargo/issues/12187) on Cargo to request this data from `cargo-metadata`).
