-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply simulate-remapped-rust-src-base even if remap-debuginfo is set in config.toml #110699
Apply simulate-remapped-rust-src-base even if remap-debuginfo is set in config.toml #110699
Conversation
… in config.toml This is really a mess. Here is the situation before this change: - UI tests depend on not having `rust-src` available. In particular, <https://github.com/rust-lang/rust/blob/3f374128ee3924514aacadf96479e17fee8f9903/tests/ui/tuple/wrong_argument_ice.stderr#L7-L8> is depending on the `note` being a single line and not showing the source code. - When `download-rustc` is disabled, we pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` `-Ztranslate-remapped-path-to-local-path=no`, which changes the diagnostic to something like ` --> /rustc/FAKE_PREFIX/library/alloc/src/collections/vec_deque/mod.rs:1657:12` - When `download-rustc` is enabled, we still pass those flags, but they no longer have an effect. Instead rustc emits diagnostic paths like this: ` --> /rustc/39c6804b92aa202369e402525cee329556bc1db0/library/alloc/src/collections/vec_deque/mod.rs:1657:12`. Notice how there's a real commit and not `FAKE_PREFIX`. This happens because we set `CFG_VIRTUAL_RUST_SOURCE_BASE_DIR` during bootstrapping for CI artifacts, and rustc previously didn't allow for `simulate-remapped` to affect paths that had already been remapped. - Pietro noticed this and decided the right thing was to normalize `/rustc/<commit>` to `$SRC_DIR` in compiletest: rust-lang@470423c - After my change to `x test core`, which rebuilds stage 2 std from source so `build/stage2-std` and `build/stage2` use the same `.rlib` metadata, the compiler suddenly notices it has sources for `std` available and prints those in the diagnostic, causing the test to fail. This changes `simulate-remapped-rust-src-base` to support remapping paths that have already been remapped, unblocking download-rustc. Unfortunately, although this fixes the specific problem for download-rustc, it doesn't seem to affect all the compiler's diagnostics. In particular, various `mir-opt` tests are failing to respect `simulate-remapped-path-prefix` (I looked into fixing this but it seems non-trivial). As a result, we can't remove the normalization in compiletest that maps `/rustc/<commit>` to `$SRC_DIR`, so this change is currently untested anywhere except locally.
r? @lcnr (rustbot has picked a reviewer for you, use r? to override) |
@bors try |
⌛ Trying commit 8785615 with merge 0f46b049864f2d971a84a3c92be916b1bbb1c842... |
☀️ Try build successful - checks-actions |
I tried to test locally that this fixes |
r? compiler |
Half this function looks like a gigantic hack to ease ui testing. I'm under the impression that there are multiple crates that attempt to do this manipulation. In metadata decoder, but also the path remapping logic in Should the downloaded rustc output FAKE_PREFIX instead of its commit hash? |
This is the way to get it to output FAKE_PREFIX. The downloaded rustc is exactly identical to a nightly, it can't unconditionally output
See my comment above:
|
How should this handle files in the standard library? If we require passing |
Thanks for the explanations. |
⌛ Testing commit 8785615 with merge 2b3db67e9cf0b4503cd5464639832198a27f00fb... |
💔 Test failed - checks-actions |
Looks spurious? Only failures are in arm-android and armhf-gnu, and they failed in the first 30 seconds without logs. @bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ebf2b37): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 659.229s -> 660.401s (0.18%) |
Stop normalizing so many different prefixes Previously, we would normalize *all* of - the absolute path to the repository checkout - the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled) - the /rustc/$sha for download-rustc - the sysroot for download-rustc Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this much simpler, but it also avoids ongoing maintenance for download-rustc and makes it much less likely that tests break by accident. - Change `tests/ui/track-diagnostics/track6.rs` to use a relative path instead of an absolute one. I am not actually sure why `track_caller` works here, but it does seem to work 🤷 - Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all suites, not just UI. In particular, mir-opt tests emit /rustc/ paths in their output. r? `@cjgillot` since you reviewed rust-lang#110699 - this is the test that it doesn't regress :)
Stop normalizing so many different prefixes Previously, we would normalize *all* of - the absolute path to the repository checkout - the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled) - the /rustc/$sha for download-rustc - the sysroot for download-rustc Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this much simpler, but it also avoids ongoing maintenance for download-rustc and makes it much less likely that tests break by accident. - Change `tests/ui/track-diagnostics/track6.rs` to use a relative path instead of an absolute one. I am not actually sure why `track_caller` works here, but it does seem to work 🤷 - Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all suites, not just UI. In particular, mir-opt tests emit /rustc/ paths in their output. r? ``@cjgillot`` since you reviewed rust-lang#110699 - this is the test that it doesn't regress :)
Stop normalizing so many different prefixes Previously, we would normalize *all* of - the absolute path to the repository checkout - the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled) - the /rustc/$sha for download-rustc - the sysroot for download-rustc Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this much simpler, but it also avoids ongoing maintenance for download-rustc and makes it much less likely that tests break by accident. - Change `tests/ui/track-diagnostics/track6.rs` to use a relative path instead of an absolute one. I am not actually sure why `track_caller` works here, but it does seem to work 🤷 - Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all suites, not just UI. In particular, mir-opt tests emit /rustc/ paths in their output. r? ```@cjgillot``` since you reviewed rust-lang#110699 - this is the test that it doesn't regress :)
This is really a mess. Here is the situation before this change:
rust-src
available. In particular,rust/tests/ui/tuple/wrong_argument_ice.stderr
Lines 7 to 8 in 3f37412
note
being a single line and not showing the source code.download-rustc
is disabled, we pass-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX
-Ztranslate-remapped-path-to-local-path=no
, which changes the diagnostic to something like--> /rustc/FAKE_PREFIX/library/alloc/src/collections/vec_deque/mod.rs:1657:12
download-rustc
is enabled, we still pass those flags, but they no longer have an effect. Instead rustc emits diagnostic paths like this:--> /rustc/39c6804b92aa202369e402525cee329556bc1db0/library/alloc/src/collections/vec_deque/mod.rs:1657:12
. Notice how there's a real commit and notFAKE_PREFIX
. This happens because we setCFG_VIRTUAL_RUST_SOURCE_BASE_DIR
during bootstrapping for CI artifacts, and rustc previously didn't allow forsimulate-remapped
to affect paths that had already been remapped./rustc/<commit>
to$SRC_DIR
in compiletest: 470423cx test core
, which rebuilds stage 2 std from source sobuild/stage2-std
andbuild/stage2
use the same.rlib
metadata, the compiler suddenly notices it has sources forstd
available and prints those in the diagnostic, causing the test to fail.This changes
simulate-remapped-rust-src-base
to support remapping paths that have already been remapped, unblocking download-rustc.Unfortunately, although this fixes the specific problem for
download-rustc, it doesn't seem to affect all the compiler's
diagnostics. In particular, various
mir-opt
tests are failing torespect
simulate-remapped-path-prefix
(I looked into fixing this butit seems non-trivial). As a result, we can't remove the normalization in
compiletest that maps
/rustc/<commit>
to$SRC_DIR
, so this change iscurrently untested anywhere except locally.
You can test this locally yourself by setting
rust.remap-debuginfo = true
, running any UI test withERROR
annotations, then rerunning the test manually with a dev toolchain to verify it prints/rustc/FAKE_PREFIX
, not/rustc/1.71.0
.Helps with #110352.