-
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
Translate the virtual /rustc/$hash
prefix back to a real directory.
#70642
Conversation
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue (this might need further optimization) |
Awaiting bors try build completion |
⌛ Trying commit 88c0d0e475bc5a086fe2669ae53cb04ad95a2eb9 with merge 72a8ca0ab60ce346eb5a4495a56e408a9dd715bc... |
// FIXME: missing sysroot spans (#53081) | ||
// ignore-i586-unknown-linux-gnu | ||
// ignore-i586-unknown-linux-musl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
☀️ Try build successful - checks-azure |
Queued 72a8ca0ab60ce346eb5a4495a56e408a9dd715bc with parent 58dd1ce, future comparison URL. |
This is great. :) "ignore on 32bit targets" was a common work-around for this before we figured out which exact targets are affected, whatever the |
Finished benchmarking try commit 72a8ca0ab60ce346eb5a4495a56e408a9dd715bc, comparison URL. |
@RalfJung 57 files mention |
There were some concerns noted here about how suggestions are exposed for cross-crate sources. Is that still a concern? Does |
@ehuss It only points to the standard library to note some things, like trait/type definitions, IME, most diagnostic logic check You can search the test suite for Ideally we'd have a way to check inside the compiler if the sources are user-editable, and only emit suggestions then, does Kind of hard to test though, unless we made some test files read-only through Bonus: if a suggestion arises while building Rust itself, then it would be fine for to point to the standard library, in some situations (we'd also get this if Cargo hinted workespaces to |
@bors try I think this looks good to land. The concern over linking to std from the sysroot seems largely fine to leave for a future discussion -- I believe it's true that this PR might make things worse (showing stuff from std as well) but it doesn't really change our decision making at all, so orthogonal to some extent. I want to check that dist artifacts aren't suddenly full of sources though (and that dist doesn't break). I don't think it will, as we only copy dylibs and rlibs and such so I think we should be fine. But good to check. Ideally we'd probably check that rustup can install rust-src tarball as well, but that's harder as we don't ship it from the try builder I think? I'll look into that separately. (That is, if nothing changed in layout then we're probably fine). |
⌛ Trying commit aba2085c320dce63d45d31257a4194ddebf1d90b with merge 5da172dc1b9c7a124a51904b96c20a79b5587292... |
⌛ Trying commit aba2085c320dce63d45d31257a4194ddebf1d90b with merge 40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4... |
Suggestions generally lean towards the assumption that the user can only change the usage of an existing API, as we assume that for example a |
☀️ Try build successful - checks-azure |
@bors p=1 |
⌛ Testing commit 8deff18 with merge 3701be0c48cbc2246d6083a56603384cc9a4a422... |
@bors retry yielding |
☀️ Test successful - checks-azure |
Rust bootstrap sysroot now has src in the same place as rust-src So we can remove a special hack. I checked this locally to confirm it works. Cc rust-lang/rust#70642 @eddyb
We may need to revert this PR if I cannot find a way to fix #70924 soonish... |
…s-issue-70924, r=eddyb Track devirtualized filenames Split payload of FileName::Real to track both real and virtualized paths. (Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`) This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR rust-lang#70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file. Fix rust-lang#70924
…cs, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc `@cbeuw` r? `@ghost`
…cs, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc ``@cbeuw`` r? ``@ghost``
…cs, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc `@cbeuw` r? `@ghost`
…, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc `@cbeuw` r? `@ghost`
…, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc `@cbeuw` r? `@ghost`
…, r=estebank Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (rust-lang#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because rust-lang#70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in rust-lang#70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see rust-lang/rfcs#3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to rust-lang#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert rust-lang#70642. Fixes rust-lang#87745. cc `@cbeuw` r? `@ghost`
Closes #53486 and fixes #53081, by undoing the remapping to
/rustc/$hash
on the fly, when appropriate (e.g. our testsuites, or user crates that depend onlibstd
), but not during the Rust build itself (as that could leak the absolute build directory into the artifacts, breaking deterministic builds).Tested locally by setting
remap-debuginfo = true
inconfig.toml
, which without these changes, was causing 56 tests to fail (see #53081 (comment) for more details).cc @Mark-Simulacrum @alexcrichton @ehuss