Repository navigation
Tracking Issue for trim-paths RFC 3127 #111540
Description
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-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
- Implement the RFC (Implement rustc part of RFC 3127 trim-paths #115214)
- Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- Should we use a slightly more complex remapping rule, like distinguishing packages from registry, git and path, as proposed in Enable --remap-path-prefix for absolute paths by default #40552?
- See Cargo's remap rules: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-trim-paths-option
- What concerns are there regarding the use of relative paths causing issues with backtraces and debuggers?
- Should we treat the current package the same as other packages?
- See Cargo's remap rules: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-trim-paths-option
-
OSOentries on macOS are not remapped (a general issue forremap-path-prefix)- See Toolchain paths are being compiled into binaires #116948 (comment)
- Is this a blocker? No. This feature is best-effort
- Will these cover all potentially embedded paths? Have we missed anything?
- What exactly is the intended use case for the "diagnostics" scope, and when would someone want to turn it on? Is that something someone would really want to enable in cargo? See --remap-path-prefix no longer works for compiler messages #87745.
- Should rustdoc support remapping (like for diagnostics)? Does remapping matter for doctests?
- doctest has supported remapping: Simplify trim-paths feature by merging all debuginfo options together #122450
- rustdoc diagnostics as well: rustdoc: use remap-path-prefix #69264 (comment)
- Deferred. Not-blocking
- On Windows PDB hasn't yet got sanitized.
- Is this a blocker? No. This feature is best-effort
- Consider the impact of back versus forward slashes, and whether or not that will work with either. See refactor: use Path::push to construct remap-path-prefix cargo#14908 (review)
- Should we remap relative paths (Cargo workspace) fix(trim-paths): custom workspace-relative member paths remap cargo#17366 (comment)
Implementation history
- Implement rustc part of RFC 3127 trim-paths #115214
- Simplify trim-paths feature by merging all debuginfo options together #122450
- feat: implement RFC 3127
-Ztrim-pathscargo#12625 - Fix
-Zremap-path-scopermeta handling #139550 - Improve
-Zremap-path-scopetests with dependency #140716 - Stabilize
-Zremap-path-scope#147611
Activity
Auto merge of rust-lang#115214 - Urgau:rfc-3127-trim-paths, r=compile…
Auto merge of rust-lang#115214 - Urgau:rfc-3127-trim-paths, r=compile…
Auto merge of rust-lang#115214 - Urgau:rfc-3127-trim-paths, r=compile…
Auto merge of rust-lang#115214 - Urgau:rfc-3127-trim-paths, r=compile…
Auto merge of rust-lang#115214 - Urgau:rfc-3127-trim-paths, r=compile…
Auto merge of #115214 - Urgau:rfc-3127-trim-paths, r=compiler-errors
Auto merge of #115214 - Urgau:rfc-3127-trim-paths, r=compiler-errors
weihanglo commentedon Nov 5, 2023
I was trying to remove
OSOsymbols on macOS. Did a research and summarized in this issue: #116948 (comment). Now, I can see that there is no way fortrim-pathsto really trim all paths unless rustc does some dirty trick for older macOS platforms. Would it be a blocker if we want to stabilize this feature, say, in 2024 edition?cc @Urgau you might be interested.
michaelwoerister commentedon Dec 12, 2023
I talked about this with @danielframpton the other day and he noticed that the current
[package name]-[version]rule for remapping might make things unnecessarily complicated for debuggers. For making the debugging experience easy to set up, it would be beneficial to require as little configuration as possible. The RFC does not explicitly make file system paths (as used by Cargo) match with how things are renamed, so in the general case the debugger needs a separate source file search path for each crate involved.However, if we prescribed that each crate from was remapped to the relative path Cargo uses inside its
$CARGO_HOME/registry/srcand$CARGO_HOME/git/checkoutsdirectories, then we have a fixed number of source directories a debugger needs to know about. The renaming would then be[registry]/[package name]-[version]for registry crates and[package name]-[sha]for git dependencies.The current
[package name]-[version]rule is already pretty close, but that seems to be by accident. It would be good to make this something that can be relied on.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
src/..then they might clash with the paths of the codebase that uses the staticlib as a dependency.61 remaining items
Rollup merge of rust-lang#147611 - stablize-remap-path-scope, r=david…
Unrolled build for #147611
Rollup merge of #147611 - stablize-remap-path-scope, r=davidtwco
Rollup merge of #147611 - stablize-remap-path-scope, r=davidtwco
ulrichard commentedon Jan 21, 2026
I am trying to build reproducibly whether I get the dependencies directly from crates.io or through artifactory on the CI server.
After stripping debug info in release builds I don't see the strings in the resulting binaries, but lots of addresses are different. My suspicion is that there is still some hash over the cache location of the dependencies.
Is this in scope for this issue?
weihanglo commentedon Jan 21, 2026
@ulrichard
That would likely be an issue of how Cargo determine rustc metadata hash. This tracking issue is for rustc to trim paths in binaries only. Please open issue in https://github.com/rust-lang/cargo/issues/new/choose with steps to repro or at least support materials that maintainers can look at. Thank you.
Auto merge of #115214 - Urgau:rfc-3127-trim-paths, r=compiler-errors
Auto merge of #122450 - Urgau:simplify-trim-paths-feature, r=michaelw…
Auto merge of #115214 - Urgau:rfc-3127-trim-paths, r=compiler-errors
Auto merge of #122450 - Urgau:simplify-trim-paths-feature, r=michaelw…
rust: kbuild: remove `--remap-path-prefix` workarounds
rust: kbuild: remove `--remap-path-prefix` workarounds
weihanglo commentedon Sep 10, 2026
FWIW, Cargo part of this feature is calling for testing. For more details, see rust-lang/cargo#12137 (comment).
feat(trim-paths): stabilize `profile.trim-paths` (rust-lang#17488)