Fix x test --doc --stage 0 library/std

[jyn514]

I managed to break this in #95449.
I am not quite sure why this is the correct fix, but it doesn't break doc --stage 0
and is strictly closer to the previous behavior.

Previously, rustdoc would error with strange issues because of the mismatched sysroot:

error[E0460]: found possibly newer version of crate `std` which `rustc_span` depends on
  --> /home/jnelson/rust-lang/rust/compiler/rustc_lint_defs/src/lib.rs:14:5
   |
14 | use rustc_span::{sym, symbol::Ident, Span, Symbol};
   |     ^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `std`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ff9290e971253a38.rlib
           crate `std`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ff9290e971253a38.so
           crate `rustc_span`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_span-ed11dce30c1766f9.rlib

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

Going to approve to get this unbroken, but I think there's two action items here: we should get these running in mingw-check or some other builder if they're too slow to verify they work in CI, and I suspect there's a missing --target argument to rustdoc which causes this when testing, probably because cross-compiling doctests is unusual. Something to look into at least.

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 69de213 has been approved by Mark-Simulacrum

[jyn514]

we should get these running in mingw-check or some other builder if they're too slow to verify they work in CI

👍 I can work on that sometime this week.

I suspect there's a missing --target argument to rustdoc which causes this when testing, probably because cross-compiling doctests is unusual

Note that none of this involved cross-compiling - I think the --target special-casing is related to build scripts and proc-macros. I don't quite understand why the rustc shim only passes the sysroot when it's present ... maybe it makes sense to unconditionally pass the sysroot, regardless of --test or --target or anything else? I'll try that locally and see what it breaks. Sorry for the mess here.

[Mark-Simulacrum]

We always pass --target to cargo, and it should always pass it down to rustc/rustdoc (I would expect) for non-host compiles. (The target is the same as the "native" triple most of the time, but it is still passed).

The detection is used so that crates like build scripts link against the previous stages sysroot (e.g., beta or stage0) which is the "native" sysroot since std might not be available for the sysroot we would otherwise try to pass. (This is my recollection. It might be slightly off.)

[jyn514]

@bors p=1 - this is breaking various things for local development

[bors]

@jyn514: 🔑 Insufficient privileges: not in try users

[Mark-Simulacrum]

@bors p=1

[bors]

⌛ Testing commit 69de213 with merge 2fa9789...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 2fa9789 to master...

[rust-timer]

Finished benchmarking commit (2fa9789): comparison url.

Summary:

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvements found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	0	0	5	0
mean2	N/A	N/A	N/A	-1.1%	N/A
max	N/A	N/A	N/A	-1.2%	N/A

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩