b9a80daac2
Consolidate staging for `rustc_private` tools This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap. The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers: - Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`) - Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc - Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice. `Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes. It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c1ed112c3dcfb5684b33772b136df0dca3. I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way. As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests. Since these changes broke Cargo, which was incorrectly using `Mode::ToolRustc`, I also changed cargo to `ToolTarget` in this PR. Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit). r? `@jieyouxu` try-job: x86_64-gnu-aux try-job: x86_64-msvc-ext1
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/book/installation.html
Documentation
If you want to contribute to rust-analyzer check out the CONTRIBUTING.md or if you are just curious about how things work under the hood, see the Contributing section of the manual.
If you want to use rust-analyzer's language server with your editor of choice, check the manual. It also contains some tips & tricks to help you be more productive when using rust-analyzer.
Security and Privacy
See the security and privacy 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
Quick Links
- Website: https://rust-analyzer.github.io/
- Metrics: https://rust-analyzer.github.io/metrics/
- API docs: https://rust-lang.github.io/rust-analyzer/ide/
- Changelog: https://rust-analyzer.github.io/thisweek
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.