bors c405509f2e Auto merge of #15560 - davidbarsky:davidbarsky/use-sysroot-rustc-to-determine-cfgs, r=Veykril
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.
2023-09-08 18:14:25 +00:00
2023-09-01 17:30:59 +02:00
2023-09-03 11:39:29 +02:00
2023-04-19 09:45:55 -04:00
2023-04-19 09:45:55 -04:00
2023-09-02 18:28:35 +03:00
fmt
2023-09-05 15:45:52 -04:00
2023-08-21 14:29:18 +01:00
2023-09-03 11:39:29 +02:00
2021-12-23 14:04:15 +02:00
2022-08-01 13:47:09 +02:00
2019-11-02 22:19:59 +03:00

rust-analyzer logo

rust-analyzer is a modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.

Quick Start

https://rust-analyzer.github.io/manual.html#installation

Documentation

If you want to contribute to rust-analyzer or are just curious about how things work under the hood, check the ./docs/dev folder.

If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Security and Privacy

See the corresponding sections of the manual.

Communication

For usage and troubleshooting requests, please use "IDEs and Editors" category of the Rust forum:

https://users.rust-lang.org/c/ide/14

For questions about development and implementation, join rust-analyzer working group on Zulip:

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer

License

rust-analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

Description
A Rust compiler front-end for IDEs
Readme 139 MiB
Languages
Rust 96.8%
HTML 1.6%
TypeScript 1.6%