-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Tracking Issue for trim-paths RFC 3127 #111540
Comments
…r-errors Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
…r-errors Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
…r-errors Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
…r-errors Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
…r-errors Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang/rust#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
Implement rustc part of RFC 3127 trim-paths This PR implements (or at least tries to) [RFC 3127 trim-paths](rust-lang/rust#111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes. `@rustbot` label: +F-trim-paths
I was trying to remove cc @Urgau you might be interested. |
I talked about this with @danielframpton the other day and he noticed that the current However, if we prescribed that each crate from was remapped to the relative path Cargo uses inside its The current This might also help with backtraces? I don't know if there is something similarly useful we can do for path dependencies.
This also came up. Unconditionally stripping the path to the current package might be too inflexible in some cases. E.g. when building a staticlib, one might want to make the paths coming from the current package identifiable in some way. If they all start with |
This plan sounds really tenable to me! Will do a change on cargo side for this, and see how people think about it. For path dependencies, maybe we could have a common prefix for them, like
Sorry I don't fully understand. Could you give a more concrete example of this? |
Implement RFC 3127 sysroot path handling changes Fix rust-lang#105907 Fix rust-lang#85463 Implement parts of rust-lang#111540 Right now, backtraces into sysroot always shows /rustc/$hash in diagnostics, e.g. ``` thread 'main' panicked at 'hello world', map-panic.rs:2:50 stack backtrace: 0: std::panicking::begin_panic at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:616:12 1: map_panic::main::{{closure}} at ./map-panic.rs:2:50 2: core::option::Option<T>::map at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:929:29 3: map_panic::main at ./map-panic.rs:2:30 4: core::ops::function::FnOnce::call_once at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ``` [RFC 3127 said](https://rust-lang.github.io/rfcs/3127-trim-paths.html#changing-handling-of-sysroot-path-in-rustc) > We want to change this behaviour such that, when rust-src source files can be discovered, the virtual path is discarded and therefore the local path will be embedded, unless there is a --remap-path-prefix that causes this local path to be remapped in the usual way. This PR implements this behaviour. When `rust-src` is present at compile time, rustc replaces /rustc/$hash with a real path into local rust-src with best effort. To sanitise this, users must explicitly supply `--remap-path-prefix=<path to rust-src>=foo`.
Maybe, yes. It's definitely worth thinking about this some more (and collecting ideas from other people).
As I understand it, the RFC states that paths from the workspace being compiled are trimmed by simply making them relative to the workspace root, that is, all file paths from workspace crates would look like Therefore it would be good, if there was some way to avoid this problem. Allowing to prepend a prefix to the relative paths might be an option. |
@michaelwoerister. Thank you for your feedback! I just opened a new issue rust-lang/cargo#13171 for further discussion about remap rules in Cargo. |
To clarify: trim-paths will still give file paths of the form EDIT: @bjorn3, would that be sufficient for your use case? |
…=wesleywiser link.exe: Don't embed full path to PDB file in binary. This PR makes `rustc` unconditionally pass `/PDBALTPATH:%_PDB%` to MSVC-style linkers, causing the linker to only embed the filename of the PDB in the binary instead of the full path. This will help implement the [trim-paths RFC](rust-lang#111540) for `*-msvc` targets. Passing `/PDBALTPATH:%_PDB%` to the linker is already done by many projects that need reproducible builds and [debugger's should still be able to find the PDB](https://learn.microsoft.com/cpp/build/reference/pdbpath) if it is in the same directory as the binary. r? `@ghost` Fixes rust-lang#87825
Here is a table that shows the various combinations of the
Observations:
My conclusion:
|
…=wesleywiser link.exe: Don't embed full path to PDB file in binary. This PR makes `rustc` unconditionally pass `/PDBALTPATH:%_PDB%` to MSVC-style linkers, causing the linker to only embed the filename of the PDB in the binary instead of the full path. This will help implement the [trim-paths RFC](rust-lang#111540) for `*-msvc` targets. Passing `/PDBALTPATH:%_PDB%` to the linker is already done by many projects that need reproducible builds and [debugger's should still be able to find the PDB](https://learn.microsoft.com/cpp/build/reference/pdbpath) if it is in the same directory as the binary. r? `@ghost` Fixes rust-lang#87825
…=wesleywiser link.exe: Don't embed full path to PDB file in binary. This PR makes `rustc` unconditionally pass `/PDBALTPATH:%_PDB%` to MSVC-style linkers, causing the linker to only embed the filename of the PDB in the binary instead of the full path. This will help implement the [trim-paths RFC](rust-lang#111540) for `*-msvc` targets. Passing `/PDBALTPATH:%_PDB%` to the linker is already done by many projects that need reproducible builds and [debugger's should still be able to find the PDB](https://learn.microsoft.com/cpp/build/reference/pdbpath) if it is in the same directory as the binary. r? `@ghost` Fixes rust-lang#87825
link.exe: Don't embed full path to PDB file in binary. This PR makes `rustc` unconditionally pass `/PDBALTPATH:%_PDB%` to MSVC-style linkers, causing the linker to only embed the filename of the PDB in the binary instead of the full path. This will help implement the [trim-paths RFC](rust-lang/rust#111540) for `*-msvc` targets. Passing `/PDBALTPATH:%_PDB%` to the linker is already done by many projects that need reproducible builds and [debugger's should still be able to find the PDB](https://learn.microsoft.com/cpp/build/reference/pdbpath) if it is in the same directory as the binary. r? `@ghost` Fixes rust-lang/rust#87825
Via #122450, it’s come to my attention that this will affect coverage instrumentation, because the coverage mappings embedded in the binary usually contain at least one absolute path, and any adjustment to those paths is constrained by the capabilities of the |
For reference, Clang allows to separately control path remapping for code coverage: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fcoverage-prefix-map |
FYI, @Urgau's PR #122450 will merge all debuginfo scopes into a single one, since splitting them did not actually solve the problem it was intended to solve (see #111540 (comment)). I'll wait for a few days before approving the PR, as to give everyone here a chance to speak up in case they disagree with the change. |
…=michaelwoerister Simplify trim-paths feature by merging all debuginfo options together This PR simplifies the trim-paths feature by merging all debuginfo options together, as described in rust-lang#111540 (comment). And also do some correctness fixes found during the review. cc `@weihanglo` r? `@michaelwoerister`
…oerister Simplify trim-paths feature by merging all debuginfo options together This PR simplifies the trim-paths feature by merging all debuginfo options together, as described in rust-lang/rust#111540 (comment). And also do some correctness fixes found during the review. cc `@weihanglo` r? `@michaelwoerister`
…oerister Simplify trim-paths feature by merging all debuginfo options together This PR simplifies the trim-paths feature by merging all debuginfo options together, as described in rust-lang/rust#111540 (comment). And also do some correctness fixes found during the review. cc `@weihanglo` r? `@michaelwoerister`
...updates? |
any movement here? still waiting on this and hoping scope didnt change from stripping all in release mode BY DEFAULT. |
Not entirely sure on rustc side of this, but I feel like it is waiting for Cargo to report back the integration status. See also: rust-lang/cargo#12137 (comment) |
Random question: are these flags meant to affect the output of diagnostics as well? One could argue that they should. |
Yes, that's the |
This is a tracking issue for the RFC 3127 (rust-lang/rfcs#3127).
This enhancement adds the
--remap-path-scope
command-line flag to control the scoping of how paths get remapped in the resulting binary.Issues: F-trim-pathsFeature: trim-paths
Documentation (rustc): https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/remap-path-scope.html
Documentation (cargo): https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-trim-paths-option
Cargo tracking issue: rust-lang/cargo#12137
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
Implementation history
-Ztrim-paths
cargo#12625The text was updated successfully, but these errors were encountered: