Repository navigation
--remap-path-prefix no longer works for compiler messages #87745
Description
Code
Create a directory and put a Rust file with bad syntax in it:
mkdir src
echo bad > src/test.rs
Then compile it with:
rustc --remap-path-prefix=src=MODIFIED src/test.rs
I expected to see output like this:
error: expected one of `!` or `::`, found `<eof>`
--> MODIFIED/test.rs:1:1
[snip]
Instead, the path is not modified and I get:
error: expected one of `!` or `::`, found `<eof>`
--> src/test.rs:1:1
[snip]
Version it worked on
rustc 1.53.0 (53cb7b0 2021-06-17)
Version with regression
rustc 1.54.0 (a178d03 2021-07-26)
Activity
nicholasbishop commentedon Aug 3, 2021
Bisected:
searched nightlies: from nightly-2021-03-17 to nightly-2021-08-03
regressed nightly: nightly-2021-05-13
searched commits: from 5c02926 to 21e92b9
regressed commit: e1ff91f
bisected with cargo-bisect-rustc v0.6.0
Host triple: x86_64-unknown-linux-gnu
Reproduce with:
apiraino commentedon Aug 5, 2021
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.
@rustbot label -I-prioritize +P-low
inquisitivecrystal commentedon Aug 7, 2021
After further discussion, there appears to be a consensus in the Prioritization Working Group that this should be
P-mediumfor the moment. Sorry for the noise!dtolnay commentedon Aug 18, 2021
FYI @cbeuw @michaelwoerister, since this bisects to #83813. Would one of you be able to take a look?
12 remaining items
michaelwoerister commentedon Aug 23, 2021
Let's pull in @rust-lang/wg-diagnostics for feedback on the intended behavior here. Here is a summary of the problem:
Translate the virtual
/rustc/$hashprefix back to a real directory. #70642 implemented a feature in the compiler that makes it emit file paths to the actual source files in the standard library if therust-srcrustup component is installed. So instead of emitting/rustc/881c1ac408d93bb7adaa3a51dabab9266e82eee8/library/std/src/panicking.rs:493:5, the compiler would emit/home/mw/.rustup/toolchains/nightly/lib/rustlib/src/rust/library/std/src/panicking.rs:493:5.This is convenient when working locally because the path points to the actual file on disk. But it broke the
--remap-path-prefixfeature (used e.g. for privacy, reproducible builds) because there we really want to avoid local file system paths ending up in the produced binary -- and there was no way to opt out of this behavior.For this reason @cbeuw implemented a fix in Fix
--remap-path-prefixnot correctly remappingrust-srccomponent paths and unify handling of path mapping with virtualized paths #83813 that made sure we emit the remapped paths (/rustc/{sha}/library/...) into output artifacts, while still emitting local file system paths for diagnostic messages.However, it turns out that sometimes (as evidenced by this issue) it is preferable to emit remapped paths for diagnostic messages too.
To me it seems that both use cases make a valid claim for either remapped or local paths to be emitted in diagnostic messages. The question is: how do we support both?
RFC rust-lang/rfcs#3127 will probably make this behavior configurable via commandline flags like
--remap-debuginfo-prefix,--remap-macro-prefix, and--remap-diagnostics-prefix. But we don't know when that RFC will be merged and in which form exactly. So for addressing this regression, I don't think we want to wait for that.So my question is: What should we do here? The options I see are:
rust-srcfunctionality until the behavior has been made configurable via the RFC.rust-srcfunctionality if any--remap-path-prefixoption (even one that does not target standard library paths) is provided torustc. That way, one can create reproducible/privacy-enabled builds even in the presence ofrust-src; but would still get real file system paths in diagnostics for the regular local workflow. This would be the compiler's behavior until the RFC defines something explicit.I'm personally in favor of the last option as it should provide a good temporary mitigation of the problem.
cbeuw commentedon Aug 23, 2021
@michaelwoerister user would have to manually supply a
--remap-path-prefixthat remaps the sysroot to something of their preference.We could provide a special codeword in
--remap-path-prefixwhich expands to the sysroot path or a separate flag, similar to the CWD proposal here rust-lang/compiler-team#450michaelwoerister commentedon Aug 26, 2021
@cbeuw, with current semantics the compiler will not remap something that already has been remapped. We would need to implement special handling for remapping the sysroot path during the special import handling for it (together with the special alias you mention). For fixing this regression in the short term, I don't think that's viable and would need an MCP like rust-lang/compiler-team#450.
michaelwoerister commentedon Aug 26, 2021
I've opened #88363 with a potential fix for this regression that does not break "sysroot de-mapping" (#70642). It still needs test case to be added and updated.
Unfortunately, I think we are already too close to the release for any fix to be backported to beta.
Rollup merge of rust-lang#88363 - michaelwoerister:remapped-diagnosti…
Rollup merge of rust-lang#88363 - michaelwoerister:remapped-diagnosti…
Rollup merge of rust-lang#88363 - michaelwoerister:remapped-diagnosti…
Auto merge of rust-lang#88363 - michaelwoerister:remapped-diagnostics…
michaelwoerister commentedon Sep 6, 2021
#88363 has landed and is on nightly. @nicholasbishop, @jsgf, @dtolnay, can you all take a look if it fixes your respective use cases?
Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank
nicholasbishop commentedon Sep 7, 2021
Looks good to me, thanks for the fix!
Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank
Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank
Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank