remove `should_render` in `PrintAttribute` derive
It just seems to be always `true`, so don't do extra work emitting extra logic just for a `true`.
cc `@jdonszelmann`
Trace some basic I/O operations in bootstrap
When working on removing the rmeta sysroot copies, it is quite difficult to figure out *why* was did a certain file appear in a given directory. This should help with that a bit.
r? `@jieyouxu`
Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups
Fixes https://github.com/rust-lang/rust/issues/145470.
First commit fixes the issue, second one performs some desperately needed cleanups.
The fix shouldn't be a breaking change because IINM the parser always ensures that all brackets are balanced (via a buffer of brackets). Meaning even though we used to accept `(use<>` as a valid precise capturing list, it was guaranteed that we would fail in the end.
Do not strip binaries in bootstrap everytime if they are unchanged
I was profiling bootstrap to figure out why a no-op build takes upward of two seconds on my machine. I found that half of that is Cargo (which is mostly unavoidable) and the rest (~900ms) is running strip. We don't need to restrip already stripped binaries all the time.
r? `@jieyouxu`
Couple of codegen_fn_attrs improvements
As noted in https://github.com/rust-lang/rust/pull/144678#discussion_r2245060329 here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
Miri: fix handling of in-place argument and return place handling
This fixes two separate bugs (in two separate commits):
- If the return place is `_local` and not `*ptr`, we didn't always properly protect it if there were other pointers pointing to that return place.
- If two in-place arguments are *the same* local variable, we didn't always detect that aliasing.
Hide docs for `core::unicode`
This module is perma-unstable and shouldn't show up in the public docs. If people want to see the docs for it, they can still run `RUSTDOCFLAGS=--document-hidden-items ./x doc library/core`.
Add tracing to various miscellaneous functions
This PR adds tracing to:
- `ty.fn_sig()`. There is only one place where `fn_sig` is called for real within `rustc_const_eval`. There are three other places where it's called, but one is inside `ConstCx::fn_sig` (which does not seem to be used anywhere), another is under `if cfg!(debug_assertions)`, and the last is within `call_main` and thus gets called only once.
- the two possible things `find_mir_or_eval_fn` can do: "emulate_foreign_item" and "load_mir"
- all calls to `Const.eval()` within the Miri or the `rustc_const_eval` codebase.
- a separate commit also fixes the style of some tracing macros
Those are all quite long-lived operations, that in total make up for 6-7% of the total time spent in the program. I found out about them by looking for long periods of time that were previously not traced at all, using this SQL query in ui.perfetto.dev:
```sql
with ordered as (select s1.*, row_number() over (order by s1.ts) as rn from slices as s1 where s1.parent_id is null and s1.dur > 0 and s1.name != "frame" and s1.name != "step" and s1.name != "backtrace") select a.ts+a.dur as ts, b.ts-a.ts-a.dur as dur, a.id, a.track_id, a.category, a.depth, a.stack_id, a.parent_stack_id, a.parent_id, a.arg_set_id, a.thread_ts, a.thread_instruction_count, a.thread_instruction_delta, a.cat, a.slice_id, "empty" as name from ordered as a inner join ordered as b on a.rn=b.rn-1 /*where b.ts-a.ts-a.dur > 5000*/ order by b.ts-a.ts-a.dur desc
```
<details>
<summary>How the table was obtained</summary>
The above image was obtained in ui.perfetto.dev with the following SQL query after obtaining a trace file by running Miri on the following Rust code with `n=100`.
```sql
select "TOTAL PROGRAM DURATION" as name, count(*), max(ts + dur) as "sum(dur)", 100.0 as "%", null as "min(dur)", null as "max(dur)", null as "avg(dur)", null as "stddev(dur)" from slices union select "TOTAL OVER ALL SPANS (excluding events)" as name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" and dur > 0 union select name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" group by name order by sum(dur) desc, count(*) desc
```
```rust
fn main() {
let n: usize = std::env::args().nth(1).unwrap().parse().unwrap();
let mut v = (0..n).into_iter().collect::<Vec<_>>();
for i in &mut v {
*i += 1;
}
}
```
</details>
<img width="1689" height="317" alt="image" src="https://github.com/user-attachments/assets/ee2c81f5-d74a-4da5-b4b6-ab2770175b14" />
dec2flt: Provide more valid inputs examples
I was just looking at the specifics of how the parsing is handled here and I wasn't sure if the examples were incomplete or the grammar below was misleading.
The grammar was correct so I figured I'd add these examples to clarify.
Rehome 37 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
Correct some grammar in integer documentation
Update "between" to "among" (more than two items), connect the "which" dependent clause to the independent part, and remove the redundant "here".
nll-relate: improve hr opaque types support
This should currently not be user-facing outside of diagnostics as even if we successfully relate the opaque types, we don't support opaque types with non-param arguments and also require all member regions to be equal to the arguments or `'static`. This means there's no way to end up with a placeholder in the hidden type.
r? types
Add `-Zindirect-branch-cs-prefix`
Cc: ``@azhogin`` ``@Darksonn``
This goes on top of https://github.com/rust-lang/rust/pull/135927, i.e. please skip the first commit here. Please feel free to inherit it there.
In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.
There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.
Tracking issue: https://github.com/rust-lang/rust/issues/116852.
MCP: https://github.com/rust-lang/compiler-team/issues/868.
Extend `QueryStability` to handle `IntoIterator` implementations
This PR extends the `rustc::potential_query_instability` lint to check values passed as `IntoIterator` implementations.
Full disclosure: I want the lint to warn about this line (please see #138871 for why): aa8f0fd716/src/librustdoc/json/mod.rs (L261)
However, the lint warns about several other lines as well.
Final note: the functions `get_callee_generic_args_and_args` and `get_input_traits_and_projections` were copied directly from [Clippy's source code](4fd8c04da0/src/tools/clippy/clippy_lints/src/methods/unnecessary_to_owned.rs (L445-L496)).
Detect missing `derive` on unresolved attribute even when not imported
When encountering unresolved attributes, ensure the proc-macros for every crate in scope are added to the `macro_map` so that typos and missing `derive`s are properly detected.
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-3.rs:20:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-3.rs:14:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-3.rs:4:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Deserialize` and `Serialize`, you might be missing a `derive` attribute
|
LL + #[derive(Deserialize, Serialize)]
LL | enum B {
|
```
Follow up to rust-lang/rust#134841. Fixrust-lang/rust#47608.
Using an error type instead of `()` avoids the duplicated errors
on `struct SUnsizedField` in `deriving-from-wrong-target.rs`. It also
improves the expanded output from this:
```
struct S2(u32, u32);
impl ::core::convert::From<()> for S2 {
#[inline]
fn from(value: ()) -> S2 { (/*ERROR*/) }
}
```
to this:
```
struct S2(u32, u32);
impl ::core::convert::From<(/*ERROR*/)> for S2 {
#[inline]
fn from(value: (/*ERROR*/)) -> S2 { (/*ERROR*/) }
}
```
The new code also only matchs on `item.kind` once.
Rollup of 19 pull requests
Successful merges:
- rust-lang/rust#140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`)
- rust-lang/rust#141744 (Stabilize `ip_from`)
- rust-lang/rust#142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`)
- rust-lang/rust#142871 (Trivial improve doc for transpose )
- rust-lang/rust#144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std)
- rust-lang/rust#144476 (rustdoc-search: search backend with partitioned suffix tree)
- rust-lang/rust#144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases)
- rust-lang/rust#144804 (Don't warn on never to any `as` casts as unreachable)
- rust-lang/rust#144960 ([RTE-513] Ignore sleep_until test on SGX)
- rust-lang/rust#145013 (overhaul `&mut` suggestions in borrowck errors)
- rust-lang/rust#145041 (rework GAT borrowck limitation error)
- rust-lang/rust#145243 (take attr style into account in diagnostics)
- rust-lang/rust#145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths)
- rust-lang/rust#145432 (cg_llvm: Small cleanups to `owned_target_machine`)
- rust-lang/rust#145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings)
- rust-lang/rust#145557 (Fix uplifting in `Assemble` step)
- rust-lang/rust#145563 (Remove the `From` derive macro from prelude)
- rust-lang/rust#145565 (Improve context of bootstrap errors in CI)
- rust-lang/rust#145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance)
Failed merges:
- rust-lang/rust#145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one)
- rust-lang/rust#145573 (Add an experimental unsafe(force_target_feature) attribute.)
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: avoid forcing all integer newtypes into memory during clear_provenance
While working on another PR I noticed locals moving into memory (via `force_allocation`) that I didn't expect to move there... turns out that is an issue I introduced when adding provenance clearing. This PR fixes that.
r? `@oli-obk`
Improve context of bootstrap errors in CI
Inspired by https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/printing.20test.20suite.20name.20by.20default/with/534920583, this PR attempts to improve the context displayed when a bootstrap invocation fails in CI.
Since https://github.com/rust-lang/rust/pull/145261, we now see the latest started step when a failure occurs. However, we can go further.
1) The first commit prints the actual executed bootstrap invocation command arguments when bootstrap ends. Since CI jobs often run multiple bootstrap commands, this makes it easier to figure out which one of them failed (before it was annoying having to search for that in CI logs). Because bootstrap doesn't really use `Result`s much, and most of them time it ends with the `detail_exit` function, which YOLOs `std::process::exit(...)`, I added the print there.
2) Adds `#[track_caller]` to a few bootstrap Cargo builder functions. This makes the log that we print when a command fails more accurate:
```
2025-08-16T18:18:51.6998201Z Command ... failed ...
2025-08-16T18:18:51.7003653Z Created at: src/bootstrap/src/core/builder/cargo.rs:423:33
2025-08-16T18:18:51.7004032Z Executed at: src/bootstrap/src/core/build_steps/doc.rs:933:26
```
Before, the `cargo.rs:XYZ` location wasn't very useful.
3) Is the most wild thing (I'll revert if you find it too magical). We store the step stack of the currently active `Builder` instance in a global variable, and when bootstrap exits with a failure, we print the stack, to make it easier to find out what was happening when a failure occurred. We could print an actual captured `Backtrace`, but I think that would be too much information in the common case. We now pass `RUST_BACKTRACE=1` on CI, so if bootstrap actually crashes unexpectedly, we would see the stacktrace.
The end of the bootsrap failure log in CI now looks like this now:
```
Bootstrap failed while executing `x build library`
---BOOTSTRAP step stack start---
Assemble { target_compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu, forced_compiler: false } }
Rustc { target: x86_64-unknown-linux-gnu, build_compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, crates: [] }
---BOOTSTRAP step stack end---
```
r? `@jieyouxu`
Remove the `From` derive macro from prelude
The new `#[derive(From)]` functionality (implemented in https://github.com/rust-lang/rust/pull/144922) caused name resolution ambiguity issues (https://github.com/rust-lang/rust/issues/145524). The reproducer looks e.g. like this:
```rust
mod foo {
pub use derive_more::From;
}
use foo::*;
#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```
It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require https://github.com/rust-lang/rust/pull/139493 to land.
I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.
Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.
Fixes: https://github.com/rust-lang/rust/issues/145524
r? ``@petrochenkov``
Remove `LlvmArchiveBuilder` and supporting code/bindings
Switching over to the newer Rust-based `ArArchiveBuilder` happened in rust-lang/rust#128936, a year ago.
Per the comment in `new_archive_builder`, that seems like enough time to justify removing the older, unused `LlvmArchiveBuilder` implementation and its associated bindings.
Fixesrust-lang/rust#128955.
cg_llvm: Small cleanups to `owned_target_machine`
This PR contains a few tiny cleanups to the `owned_target_machine` code.
Each individual commit should be fairly straightforward.
cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths
We had an issue on our LLVM-head Rust builder where it got stuck with this test failing because it was reusing the tmpdir between runs and something broke the incremental compile. Everything seems to work fine with run_in_tmpdir in this test. tests/run-make/uefi-qemu also uses the same tmpdir across runs, but I don't have the right environment to test that so I didn't try fixing it. That is the only use of std::env::temp_dir left in run-make tests after this fix.
take attr style into account in diagnostics
when the original attribute was specified as an inner attribute, the suggestion will now match that attribute style
rework GAT borrowck limitation error
The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization.
This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in https://github.com/rust-lang/rust/pull/140737#discussion_r2259592651.
r? types cc ```@amandasystems```
overhaul `&mut` suggestions in borrowck errors
* This refactors the logic so that it does not use fuzzy string matching for suggestions; it instead uses information directly from MIR.
* If something comes from a custom `Index` impl for which the `IndexMut` trait does not apply, do not suggest adding `mut` after `&`.
* Suggest `get_mut` with `unwrap` if error is fired on `BTreeMap` or `HashMap`.
Supersedes rust-lang/rust#144018 cc ```@xizheyin```
Closesrust-lang/rust#143732
[RTE-513] Ignore sleep_until test on SGX
rust-lang/rust#141829 added a test for `sleep_until`: it checks whether its specification holds:
> Puts the current thread to sleep until the specified deadline has passed.
but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls.
The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
Don't warn on never to any `as` casts as unreachable
I'm doing this while being sleep deprived on a night train, let's hope this is coherent.
Fixesrust-lang/rust#67227
Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases
This PR resolves several test failures encountered when running `./x test` on the RISC-V architecture. These failures were caused by platform-specific behavior, ABI differences, or codegen inconsistencies unique to RISC-V.
The following test cases have been fixed to ensure compatibility with RISC-V:
* `codegen-llvm/enum/enum-match.rs`
* `codegen-llvm/enum/enum-transparent-extract.rs`
* `codegen-llvm/repeat-operand-zero-len.rs`
* `codegen-llvm/enum/enum-aggregate.rs`
* `codegen-llvm/uninhabited-transparent-return-abi.rs`
In addition, this PR adjusts `tests/codegen-llvm/transmute-scalar.rs` to explicitly specify the target architecture:
```rust
//@ compile-flags: --target=x86_64-unknown-linux-gnu
//@ needs-llvm-components: x86
```
As suggested by ```@nikic,``` this test is not target-specific and already uses `minicore`, implying it is meant to run against a stable triple regardless of the host architecture. Explicitly setting the target ensures consistent codegen behavior, particularly when testing on non-x86 platforms such as riscv64.
All changes have been tested locally on a RISC-V target and now pass as expected.
### Notes:
* These fixes are scoped specifically to enable full test suite compliance for RISC-V.
* No changes impact other architectures.
* The change to `transmute-scalar.rs` aligns with the intent of [[#143915](https://github.com/rust-lang/rust/pull/143915)](https://github.com/rust-lang/rust/pull/143915) and prevents architecture-dependent discrepancies during CI or local testing.
rustdoc-search: search backend with partitioned suffix tree
Before:
- https://notriddle.com/windows-docs-rs/doc-old/windows/
- https://doc.rust-lang.org/1.89.0/std/index.html
- https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html
After:
- https://notriddle.com/windows-docs-rs/doc/windows/
- https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html
- https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html
## Summary
Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called [stringdex](https://crates.io/crates/stringdex), that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, *incremental* algorithm.
## Motivation
Fixes https://github.com/rust-lang/rust/issues/131156
While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's.
Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever [place new matches on top of old ones](https://web.dev/articles/cls). It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running.
## Explanation
A longer description of how name search works can be found in stringdex's [HACKING.md](https://gitlab.com/notriddle/stringdex/-/blob/main/HACKING.md) file.
Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match.
## Drawbacks
It's rather complex, and takes up more disk space than the current flat list of strings.
## Rationale and alternatives
Instead of a suffix tree, I could've used a different [approximate matching data structure](https://en.wikipedia.org/wiki/Approximate_string_matching). I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match [oepn](https://doc.rust-lang.org/nightly/std/?search=oepn) like the current system does).
## Prior art
[Sherlodoc](https://github.com/art-w/sherlodoc) is based on a similar concept, but they:
- use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here
- use substring matching for name-based search, [but not fuzzy name matching](https://github.com/art-w/sherlodoc/issues/21)
- actually implement body text search, which is a potential-future feature, but not implemented in this PR
## Future possibilities
### Low-level optimization in stringdex
There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself.
- Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be.
- Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit)
- The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them.
- Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb.
### Improved recall in type-driven search
Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want.
What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise.
For example, a type theoretical improvement would fix [`Iterator<T>, (T -> U) -> Iterator<U>`](https://doc.rust-lang.org/nightly/std/?search=Iterator%3CT%3E%2C%20(T%20-%3E%20U)%20-%3E%20Iterator%3CU%3E) to give [`Iterator::map`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.map), because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one.
## Full-text search
Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching.
Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks:
- You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter.
- Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat.
Neither of these problems are deal-breakers, but they're worth keeping in mind.
Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std
Before, when bootstrap did a check build of rustc stage N (with a build compiler that was stage N-1), it automatically copied the resulting `.rmeta` artifacts into the sysroot of the stage N-1 build compiler, so that stage N `rustc_private` tools such as `miri` could be compiled using the stage N-1 build compiler. This has a number of issues:
- It was done unconditionally, even if no `rustc_private` tools were actually built.
- If we did a check and a build of the same stage compiler in the same bootstrap invocation, the generated rmeta and rlib files could clash. This is also why you can see that `check::Std` actually doesn't copy the artifacts anymore (which forced us to build std instead of just checking it in a bunch of `Check` steps).
- It was polluting the sysroot of the build compiler. This is especially annoying for the stage 0 compiler, because we are forced to create an artificial sysroot for it, so that we can copy new stuff into it.
- It was very implicit in bootstrap.
Based on suggestions by ```@cuviper``` and ```@bjorn3,``` I tried to change how this behaves. Instead of copying the rmeta artifacts into the sysroot of the build compiler (from where they would be loaded implicitly), they are now stored in a separate transient bootstrap build directory, and they are then explicitly passed *only* when checking `rustc_private` tools using the `-L` flag. The flags are passed out-of-band through our rustc wrapper, to avoid invalidating the build cache. This is the first commit.
The second commit does the same for std. For a few months, we used to build std instead of just checking it when doing a cross-compile check of something that required std, this now fixes it. There is still the previous ordering requirement though, that `check::Std` has to be executed as the last check step, or rather nothing that requires checked std should be executed *after* it, because it will run into rmeta/rlib duplications (4fa90ef799/src/bootstrap/src/core/builder/mod.rs (L1066)). I tried to fix in this PR, but it quickly runs into the fact that building things currently copies *rlib* artifacts into the build compiler sysroot. I want to fix that as one of the next steps. After we get rid of all the copies (or rather, we only do the copies for dist/stage2+ and do not copy anything into the stage0 compiler's sysroot), we could hopefully finally get rid of `stage0-sysroot`.
Based on my local tests, this seems to be working fine. If it works on CI, and we don't run into other issues after merging it, I'd like to do the same also for rlib artifacts generated during `x build`.
r? ```@jieyouxu```
