-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
--remap-path-prefix no longer works for compiler messages #87745
Comments
Bisected: searched nightlies: from nightly-2021-03-17 to nightly-2021-08-03 bisected with cargo-bisect-rustc v0.6.0Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2021-03-17 --preserve --script=./bisect-check.py |
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-low |
After further discussion, there appears to be a consensus in the Prioritization Working Group that this should be |
FYI @cbeuw @michaelwoerister, since this bisects to #83813. Would one of you be able to take a look? |
I thought this is the intended behaviour? The local path is not embedded into a compilation output. Compiler diagnostics should give you the local path |
For Buck's use case of Before: --> eden/mononoke/commit_rewriting/megarepo/src/history_fixup_delete.rs:55:13 After regression: --> buck-out/dev/bin/aab7ed39/eden/mononoke/commit_rewriting/megarepo/megarepolib#platform009-clang,rlib-pic/eden/mononoke/commit_rewriting/megarepo/src/history_fixup_delete.rs:55:13 Context: in a monorepo codebase, all the source files have a canonical path relative to the root of the monorepo. Those are the files that the engineer edits as part of day-to-day development. For rustc invocations though, the paths fed into the compiler by Buck are nested somewhere inside a Buck-managed directory. This is necessary for example in order to overlay generated sources into that directory side by side with the handwritten sources. |
wg-prioritization got confused about this too, which is part of why we had so much trouble prioritizing this correctly. @nicholasbishop pointed out to us that the old behavior was intentional. It's actually part of the documentation for the flag:
|
No it's a regression. The original intended behavior is to remap diagnostic paths as well. I saw #83813 go by but I didn't realize it changed diagnostic behaviour or I would have flagged it. Were there tests for this? |
I also thought that the intended behavior has changed after #70642 and the consensus was that diagnostics should not be remapped, so that one gets "real" file system paths in error messages that one can click on / copy & paste, etc. I'm wondering if we need to make this behavior configurable. It looks like there is no solution that is correct in all use cases. @cbeuw, does your RFC cover this already maybe? |
@michaelwoerister In our use case, the one @dtolnay presented above, we're using I believe the idea to remap diagnostic paths came from me in #38322 (comment) and you implemented this in #41508 specifically noting that it also covers error messages. So as far as this issue goes, not mapping error paths is a regression from the designed behaviour of (I'd really like to avoid having two distinct subtly-interacting features covering the same area.) |
@michaelwoerister My original RFC doesn't cover this (as it was solely to do with Cargo). In response to the RFC feedback, my rust-lang/rfcs#3127 (comment) suggested that we have two extra remapping flags for rustc, one controlling only debuginfo and one controlling only For now, if we are set that printing remapped path in diagnostics is the right behaviour for @jsgf rust/compiler/rustc_metadata/src/rmeta/decoder.rs Lines 1767 to 1863 in 7960030
When rustc exports metadata for the current crate, paths not affected by rust/compiler/rustc_span/src/lib.rs Lines 200 to 204 in 7960030
|
@jsgf Yes, I think I have read too much into the changes in #70642. I think this is a regression and I would consider it I am wondering what to do about the @cbeuw, would you be up for working with me on fixing the regression? If we are quick, we might still be able backport it to the current beta. |
One problem I just noticed: if we default to emitting remapped paths in error messages again then we will effectively break the |
@michaelwoerister Regarding #70642, could we just drop the virtual path on sysroot files when |
@cbeuw, I'm afraid that that would effectively re-introduce #73167. Code instantiated from the standard library would again refer to the local path, even in debuginfo and panic messages, and there would be no way to opt-out of that short of uninstalling the |
Let's pull in @rust-lang/wg-diagnostics for feedback on the intended behavior here. Here is a summary of the problem:
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 So my question is: What should we do here? The options I see are:
I'm personally in favor of the last option as it should provide a good temporary mitigation of the problem. |
@michaelwoerister user would have to manually supply a We could provide a special codeword in |
@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. |
…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`
#88363 has landed and is on nightly. @nicholasbishop, @jsgf, @dtolnay, can you all take a look if it fixes your respective use cases? |
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang/rust#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #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 #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/rust#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642. Fixes rust-lang/rust#87745. cc `@cbeuw` r? `@ghost`
Looks good to me, thanks for the fix! |
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in rust-lang/rust#83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #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 #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/rust#88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642. Fixes rust-lang/rust#87745. cc `@cbeuw` r? `@ghost`
Code
Create a directory and put a Rust file with bad syntax in it:
Then compile it with:
I expected to see output like this:
Instead, the path is not modified and I get:
Version it worked on
rustc 1.53.0 (53cb7b0 2021-06-17)
Version with regression
rustc 1.54.0 (a178d03 2021-07-26)
The text was updated successfully, but these errors were encountered: