-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Introduce -Z remap-cwd-prefix switch #87320
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon. Please see the contribution instructions for more information. |
This comment has been minimized.
This comment has been minimized.
Why |
compiler/rustc_session/src/config.rs
Outdated
.into_iter() | ||
.map(|(i, s)| (i, RemapType::CompilationDir(s))), | ||
); | ||
positions.sort_by(|a, b| a.0.cmp(&b.0)); |
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.
I assume the intent here is to make sure the relative ordering of remap-path-prefix
and debug-compilation-dir
options is preserved. But I wonder how much that matters? Presumably the remap-path-prefix
option won't contain the cwd as a prefix, since avoiding that is the whole point of debug-compilation-dir
.
Also will there ever be more than one instance of debug-compilation-dir
? What does it mean to map the cwd multiple times?
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.
That's right. I don't know that it matters much, I don't expect that most people would be mixing these, but it made for an easy way to make something well-defined, rather than one command-line argument having precedence over the other.
It would be slightly simpler code to not maintain the ordering, but I considered it a net win to have something more easily explained. In this case --debug-compilation-dir
acts exactly like an alias for remap-path-prefix=$(pwd)=
. Anything else seems to require more explanation in the docs, and more risk of an arbitrary change breaking some edge case in the future.
I mentioned it on here: #38322 (comment) I was just copying the name from Clang, but I am not tied to it. Happy to rename to whatever you prefer. If you like --remap-path-cwd (I like it too) then I'll use that, just let me know. |
Yeah, I think consistency with rustc's existing options is more important than being consistent with clang's. |
compiler/rustc_session/src/config.rs
Outdated
RemapType::CompilationDir(to) => match std::env::current_dir() { | ||
Err(_) => early_error( | ||
error_format, | ||
"Unable to determine current directory for \ | ||
--debug-compilation-dir", | ||
), | ||
Ok(from) => (PathBuf::from(from), PathBuf::from(to)), |
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.
This only matches the precise cwd, not a trailing slash, so you're required to map to a non-empty path. So /home/me/src/foo.rs
with a cwd of /home/me
can only be mapped to ./src/foo.rs
. But if you match against /home/me/
then you can choose to map it to '' giving src/foo.rs
which is a bit cleaner. But that means you need to take the current path separator into account.
This implementation also has the pitfall that it will remap /home/meat/src/bar.rs
to at/src/bar.rs
since --remap-path-prefix
works strictly on strings without regard to path separators.
I think there's an opportunity to discuss a more pathname-aware prefix-replacement algorithm, but there are a lot of edge cases to take into account (the current algorithm, for all its faults, is very simple to explain).
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.
It’s cleaner without the path separator but there’s no less functionality with it, right?
If you wanted to specify a different prefix you can with something like “/foo/.” which would translate “/home/me/src/file.rs” into “/foo/./src/file.rs”. It’s not how you’d normally write it by hand, but it functions just fine, and is universally deterministic. Is it worth it to you to add extra code in here to avoid some dots in command lines?
This implementation also has the pitfall that it will remap /home/meat/src/bar.rs to at/src/bar.rs
Yes, true. However as this path will be rooted at the current working directory, all paths have the same prefix, so this shouldn’t actually come up, right?
Is there something we need to change here with the preexisting flag? Or could that be considered separately? The way this new flag is defined, as an alias for —remap-path-prefix, would allow for the existing flag to evolve and both command line flags could change in tandem.
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.
You wouldn't be able to map a path to src/foo.rs
with no prefix, and random intermixing of ``, ./
or even `././` gets messy esp if you're trying to be careful because of exact string matching. But no, not the end of the world.
Edit: it's implemented in terms of Path::strip_prefix
, which ignores spurious ./
foo//bar
, etc, so its more robust than plain string matching. It also won't be confused by partial components in the prefix.
rust/compiler/rustc_span/src/source_map.rs
Line 1026 in 7db08ee
if let Ok(rest) = path.strip_prefix(from) { |
Thanks for the PR, @danakj! Since this would introduce a new stable compiler flag, would you mind opening a major change proposal for it? It looks like this needs some careful design work. I also recommend to word the MCP such that it proposes adding an unstable flag (i.e. |
Thanks @michaelwoerister for pointing me to the MFP process, I was not aware of it. I will come back with that later today. |
26f4afe
to
a1bbe73
Compare
Side note: This feature (or something that encompasses it's functionality) might also be a good step towards improving the privacy situation around absolute paths (see for example #64839). |
There is a related RFC: rust-lang/rfcs#3127, which utilises Cargo to supply different |
@cbeuw, am I correct in assuming that the functionality implemented in this PR would not interfere with rust-lang/rfcs#3127? |
same execution will work on all machines, regardless of build environment. | ||
|
||
This is an unstable option. Use `-Z remap-cwd-prefix=val` to specify a value. | ||
|
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.
As long as this option is unstable it needs to be documented under https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book/src/compiler-flags rather than here.
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.
@danakj, would you mind moving this piece of documentation to the "unstable book" (as mentioned above)? Otherwise it would show up in the regular documentation which is only meant for stable features.
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.
Yes absolutely. I’ll be back at work next week and will do so then. Thanks very much!
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.
I've moved the documentation over.
I believe that #87325 needs a tracking bug label attached to it, as well as an unstable label? But I am unable to do that. I thought of filing a new tracking but, but then I can't add the other labels it has.
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.
I went ahead and opened #89434 as a dedicated tracking issue.
I have no concerns about an option which is effectively equivalent to I think it's useful to have a late-binding cwd remapping for the cases where one doesn't know what the working directory will be at command-line construction time and don't want to interpose a shell to do backtick (or equiv) expansion. |
✌️ @danakj can now approve this pull request |
bors try is likely to be useless as-is. It doesn't run any tests, only builds a dist build for x86_64-unknown-linux-gnu, which likely works OK if the CI builders are passing. You can enable a subset of the builders an r+ will trigger by editing this section and adding the builders above that (by copying them down) and then run ./x.py run src/tools/expand-yaml-anchors to generate the actual CI configuration. After that, bors try will run the selected targets. Please limit this to just a few CI builders at a time. |
This disables the remap_cwd_bin test which is failing on windows, and adds a test for --remap-path-prefix making a bin crate instead, to see if it will fail the same way.
@bors try |
⌛ Trying commit 4933be9 with merge 1e88e879f6e3d88c9b77998b1cac615454a9e10e... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
I disabled my new |
These tests fail on Windows, as the build is not deterministic there for bin targets. Issue rust-lang#88982 is filed for this problem.
Also, thank you Manish and Mark for your assistance in navigating the maze of Rust CI and PR submission :) I really appreciate the help! |
@bors r=michaelwoerister (new test looks fine) I'm going to let this stay in rollup=iffy mode but I might include it in my own rollups. The advantage of rollup=iffy is that you get priority over most of the other PRs for non-rollups so if there are still issues you'll find out quickly (queue is a bit backed up rn though) |
📌 Commit c011828 has been approved by |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
…arth Rollup of 8 pull requests Successful merges: - rust-lang#87320 (Introduce -Z remap-cwd-prefix switch) - rust-lang#88690 (Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ) - rust-lang#88775 (Revert anon union parsing) - rust-lang#88841 (feat(rustc_typeck): suggest removing bad parens in `(recv.method)()`) - rust-lang#88907 (Highlight the `const fn` if error happened because of a bound on the impl block) - rust-lang#88915 (`Wrapping<T>` has the same layout and ABI as `T`) - rust-lang#88933 (Remove implementation of `min_align_of` intrinsic) - rust-lang#88951 (Update books) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This switch remaps any absolute paths rooted under the current
working directory to a new value. This includes remapping the
debug info in
DW_AT_comp_dir
andDW_AT_decl_file
.Importantly, this flag does not require passing the current working
directory to the compiler, such that the command line can be
run on any machine (with the same input files) and produce the
same results. This is critical property for debugging compiler
issues that crop up on remote machines.
This is based on adetaylor's dbc4ae7
Major Change Proposal: rust-lang/compiler-team#450
Discussed on #38322. Would resolve issue #87325.