Add dedicated field for `target_dir` in the configurations for Cargo
and Flycheck. Also change the directory to be a `PathBuf` as opposed to
a `String` to be more appropriate to the operating system.
project-model: when using `rust-project.json`, prefer the sysroot-defined rustc over discovery in `$PATH`
At the moment, rust-analyzer discovers `rustc` via the `$PATH` even if the `sysroot` field is defined in a `rust-project.json`. However, this does not work for users who do not have rustup installed, resulting in any `cfg`-based inference in rust-analzyer not working correctly. In my (decently naive!) opinion, it makes more sense to rely on the `sysroot` field in the `rust-project.json`.
One might ask "why not add `rustc` to the `$PATH`?" That is a reasonable question, but that doesn't work for my use case:
- The path to the sysroot in my employer's monorepo changes depending on which platform a user is on. For example, if they're on Linux, they'd want to use the sysroot defined at path `a`, whereas if they're on macOS, they'd want to use the sysroot at path `b` (I wrote the sysroot resolution functionality [here](765da4ca1e/integrations/rust-project/src/sysroot.rs (L39)), if you're curious).
- The location of the sysroot can (and does!) change, especially as people figure out how to make Rust run successfully on non-Linux platforms (e.g., iOS, Android, etc.) in a monorepo. Updating people's `$PATH` company-wide is hard while updating a config inside a CLI is pretty easy.
## Testing
I've created a `rust-project.json` using [rust-project](https://github.com/facebook/buck2/tree/main/integrations/rust-project) and was able to successfully load a project with and without the `sysroot`/`sysroot_src` fields—without those fields, rust-analyzer fell back to the `$PATH` based approach, as evidenced by `[DEBUG project_model::rustc_cfg] using rustc from env rustc="rustc"` showing up in the logs.
Deduplicate crates when extending crate graphs
This is quadratic in runtime per deduplication attempt, but I don't think that'll be a problem for the workload here. Don't be scared of the diff, the actual diff is +42 -22, the rest is tests and test data.
Fixes https://github.com/rust-lang/rust-analyzer/issues/14476
Detect sysroot dependencies using symlink copy
cc #7637
It is currently in a proof of concept stage, and it doesn't generates a copy. You need to provide your own sysroot copy in `/tmp/ra-sysroot-hack` in a way that `/tmp/ra-sysroot-hack/library/std/lib.rs` exists and `/tmp/ra-sysroot-hack/Cargo.toml` is [the one from this comment](https://github.com/rust-lang/rust-analyzer/issues/7637#issuecomment-1495008329). I will add the symlink code if we decide that this approach is not a dead end.
It seems to somehow work on my system. Go to definition into std dependencies works, type checking can look through fields if I make them public and `cfg_if` appears to work (I tested it by hovering both sides and seeing that the correct one is enabled). Though finding layout of `HashMap` didn't work.
Please try it and let me know if I should go forward in this direction or not.
