feat(trim-paths): emit unremap files for final artifacts by weihanglo · Pull Request #17303 · rust-lang/cargo

weihanglo · 2026-08-03T03:56:48Z

What does this PR try to resolve?

Part of #12137.
This was discussed during 2026 all-hands
rust-lang/all-hands-2026#38 (comment)

This implements the unremap file discussed in 2026 All-Hands.
The logic basically follows the unstable SBOM file generation.
See rust-lang/all-hands-2026#38 (comment)
for the concept of the unremap file.

See the doc update commit for more about the file format.

An example of the unremap file:

{"v":1}
{"rust_version":"1.96.0-nightly","workspace_root":"/home/me/app"}
{"from":"/cargo/build-dir","to":"/home/me/app/target"}
{"from":"/cargo/registry/6f17d22d3f0a95d1","to":"/home/me/.cargo/registry/src/index.crates.io-6f17d22d3f0a95d1"}
{"from":"/rustc/abc123","to":"/home/me/.rustup/toolchains/nightly/lib/rustlib/src/rust"}

How to test and review this PR?

Commit by commit.

The doc update should have the most descriptive information for the format.

Note

Stacked PR doesn't work with cross-forks stacks 😭😭😭

Stacked pull requests require all branches to be in the same repository. Cross-fork stacks are not supported.

https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/creating-stacked-pull-requests

(work on my fork btw weihanglo#97)

rustbot · 2026-08-03T03:56:52Z

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @epage, @weihanglo
@epage, @weihanglo expanded to epage, weihanglo

epage · 2026-08-03T18:22:11Z

+        out.write_all(b"\n")?;
+    }
+
+    Ok(())


Do we need any kind of tag for each json blob?

View changes since the review

Do you have any suggested schema? I feel like this is simple enough and already versioned, so probably doesn't need to?

Let's merge this as-is and put this on the tracking issue.

epage · 2026-08-03T18:27:13Z

                    outputs.extend(sbom_files.into_iter());
                }
+
+                // Only generates unremap files for root units.


Thinking back to my debugger days, I feel like a user would just want a general remap file for all of their artifacts. However, that gets weird from a rebuild perspective unless we have remaps as intermediate artifacts and have a merge step.

On the other hand, these aren't files they can use directly anyways, so they can manually merge the results.

View changes since the review

I think you have the point. What they commonly get in a unremap file would be

One build-dir remap

One sysroot remap

One remap per registry

One remap per (Git repo, rev)

One remap per path dep outside workspace

People rarely use non-workspace path deps. Custom registry is not common but also not that common. People tend to be on the same rev for each git dep, and usually tend to have git dep as possible as they can.

I feel like for most projects they'll have build-dir + sysroot + crates.io registry unremap files, which is identical for all binaries. If we can merge, that we can write less files.

However, that gets weird from a rebuild perspective unless we have remaps as intermediate artifacts and have a merge step.

Yeah that make things weird, and also we already work on root units so it would be way less except for projects like bevy that has tons of examples. I am not sure which direction we'd like to go.

Okay, one counterargument not inclining with a unified unremap file: Different binaries with the same PackageId path-dep-outside-workspace may collide in the unremap file.

Probably not possible in the same lockfile. I think I was wrong

Let's merge this as-is and put this on the tracking issue.

Split remap rule logic into its `(<from>, <to>)` pair as return values. This is meant to be used in unremap file generation.

rustbot · 2026-08-04T01:19:45Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

This implements the unremap file discussed in 2026 All-Hands. The logic basically follows the unstable SBOM file generation. See <rust-lang/all-hands-2026#38 (comment)> for the concept of the unremap file. See the doc update commit for more about the file format. An example of the unremap file: ```json {"v":1} {"rust_version":"1.96.0-nightly","workspace_root":"/home/me/app"} {"from":"/cargo/build-dir","to":"/home/me/app/target"} {"from":"/cargo/registry/6f17d22d3f0a95d1","to":"/home/me/.cargo/registry/src/index.crates.io-6f17d22d3f0a95d1"} {"from":"/rustc/abc123","to":"/home/me/.rustup/toolchains/nightly/lib/rustlib/src/rust"} ```

Urgau · 2026-08-04T15:37:50Z

I was worried having the file as json would be an issue since rust-gdb and rust-lldb are both shell scripts, but I've confirmed locally that both gdb and lldb can load arbitrary python scripts with sufficient API access to be able to load the <exe>.trim-paths.jsonl file and set the substitution paths.

Thanks for adding the unremap file.

Urgau · 2026-08-04T15:39:31Z

Btw, what's the rational for "file-level metadata" line, when is it expected to be used?

weihanglo · 2026-08-04T16:27:00Z

Btw, what's the rational for "file-level metadata" line, when is it expected to be used?

Debugger substitutions are sessionp-global AFAIK. If we have {"from":".","to":"/my/project/ws"} the substitution may collide between artifacts from different workspaces. (Say you have a dylib form one and bin from the other). Having it as file level metadata lets consumer to decide what to do. and for normal from/to records they can blindly apply. It is also informative enough to let people know where it came from.

As for rustc_version, it is basically a producer provenance, also indicating that you might want to use the same Rust toolchaion version to fetch and prepare those dependency source.

Update cargo submodule 21 commits in 7c83d4cc0953b81d823e47d640c64da9b8bd4fac..c79e8f89441b3e73d6d65d125c0c745792808c74 2026-07-29 21:34:53 +0000 to 2026-08-04 19:17:33 +0000 - fix(diag): Ensure diagnostic titles work without snippets (rust-lang/cargo#17304) - refactor: Remove unnecessary mut in sources (rust-lang/cargo#17305) - feat(trim-paths): emit unremap files for final artifacts (rust-lang/cargo#17303) - fix: prevent panic when `package.build` is empty (rust-lang/cargo#17268) - Add a suggestion when adding `[lints]` to a workspace to use `[workspace.lints]` instead (rust-lang/cargo#17300) - chore(deps): update embarkstudios/cargo-deny-action action to v2.1.1 (rust-lang/cargo#17291) - refactor: move sysroot lookup to GlobalContext (rust-lang/cargo#17276) - fix(trim-paths): unambiguous and reversible remap rules (rust-lang/cargo#17302) - Avoid parsing unchanged lockfiles (rust-lang/cargo#17301) - Remove unnecessary to_path_buf (rust-lang/cargo#17295) - chore(deps): update cargo-semver-checks to v0.50.0 (rust-lang/cargo#17297) - chore(deps): update actions/checkout action to v6.1.0 (rust-lang/cargo#17290) - Remove unnecessary return at end of functions (rust-lang/cargo#17292) - make __CARGO_TEST_FORCE_ARGFILE available in distributed builds (rust-lang/cargo#17293) - Fix manual_readme lint for lower-priority README files (rust-lang/cargo#17208) - fix(git): make checkout names independent of git config (rust-lang/cargo#17289) - fix(diag): Rename redundant_readme to manual_readme (rust-lang/cargo#17288) - Remove redundant double call .to_string() (rust-lang/cargo#17286) - fix(completions): complete paths for cargo run arguments (rust-lang/cargo#17284) - test(git): exercise multi git revision lockfile (rust-lang/cargo#17279) - add context to lints documentation (rust-lang/cargo#17273) r? ghost

…rk-Simulacrum Add nightly-only support for Cargo unremap trim-paths files in `rust-gdb` This PR adds support in `rust-gdb` for the un-remapping file produced by Cargo with `-Ztrim-paths` (rust-lang/cargo#17303). This support is nightly-only, and only activated when `RUST_GDB_TRIM_PATHS=unstable` is set. An example of the unremap file: ```json {"v":1} {"rust_version":"1.96.0-nightly","workspace_root":"/home/me/app"} {"from":"/cargo/build-dir","to":"/home/me/app/target"} {"from":"/cargo/registry/6f17d22d3f0a95d1","to":"/home/me/.cargo/registry/src/index.crates.io-6f17d22d3f0a95d1"} {"from":"/rustc/abc123","to":"/home/me/.rustup/toolchains/nightly/lib/rustlib/src/rust"} ```

Update cargo submodule 21 commits in 7c83d4cc0953b81d823e47d640c64da9b8bd4fac..c79e8f89441b3e73d6d65d125c0c745792808c74 2026-07-29 21:34:53 +0000 to 2026-08-04 19:17:33 +0000 - fix(diag): Ensure diagnostic titles work without snippets (rust-lang/cargo#17304) - refactor: Remove unnecessary mut in sources (rust-lang/cargo#17305) - feat(trim-paths): emit unremap files for final artifacts (rust-lang/cargo#17303) - fix: prevent panic when `package.build` is empty (rust-lang/cargo#17268) - Add a suggestion when adding `[lints]` to a workspace to use `[workspace.lints]` instead (rust-lang/cargo#17300) - chore(deps): update embarkstudios/cargo-deny-action action to v2.1.1 (rust-lang/cargo#17291) - refactor: move sysroot lookup to GlobalContext (rust-lang/cargo#17276) - fix(trim-paths): unambiguous and reversible remap rules (rust-lang/cargo#17302) - Avoid parsing unchanged lockfiles (rust-lang/cargo#17301) - Remove unnecessary to_path_buf (rust-lang/cargo#17295) - chore(deps): update cargo-semver-checks to v0.50.0 (rust-lang/cargo#17297) - chore(deps): update actions/checkout action to v6.1.0 (rust-lang/cargo#17290) - Remove unnecessary return at end of functions (rust-lang/cargo#17292) - make __CARGO_TEST_FORCE_ARGFILE available in distributed builds (rust-lang/cargo#17293) - Fix manual_readme lint for lower-priority README files (rust-lang/cargo#17208) - fix(git): make checkout names independent of git config (rust-lang/cargo#17289) - fix(diag): Rename redundant_readme to manual_readme (rust-lang/cargo#17288) - Remove redundant double call .to_string() (rust-lang/cargo#17286) - fix(completions): complete paths for cargo run arguments (rust-lang/cargo#17284) - test(git): exercise multi git revision lockfile (rust-lang/cargo#17279) - add context to lints documentation (rust-lang/cargo#17273) r? ghost

Rollup merge of #160560 - Urgau:trim-paths-gdb-support, r=Mark-Simulacrum Add nightly-only support for Cargo unremap trim-paths files in `rust-gdb` This PR adds support in `rust-gdb` for the un-remapping file produced by Cargo with `-Ztrim-paths` (rust-lang/cargo#17303). This support is nightly-only, and only activated when `RUST_GDB_TRIM_PATHS=unstable` is set. An example of the unremap file: ```json {"v":1} {"rust_version":"1.96.0-nightly","workspace_root":"/home/me/app"} {"from":"/cargo/build-dir","to":"/home/me/app/target"} {"from":"/cargo/registry/6f17d22d3f0a95d1","to":"/home/me/.cargo/registry/src/index.crates.io-6f17d22d3f0a95d1"} {"from":"/rustc/abc123","to":"/home/me/.rustup/toolchains/nightly/lib/rustlib/src/rust"} ```

@weihanglo

…ut (rust-lang#17356) ### What does this PR try to resolve? See rust-lang#17354 (comment) for the motivating context. In rust-lang#17303 we started emitting unremap files to final artifacts. This included logic for cleaning the unremap file when running `cargo clean -p` but the logic was not added in the `.build_dir_new_layout` branch in the cargo clean logic. This PR adds the logic to both branches. ### How to test and review this PR? Primarily using the existing tests r? @weihanglo

Update cargo submodule 21 commits in 7c83d4cc0953b81d823e47d640c64da9b8bd4fac..c79e8f89441b3e73d6d65d125c0c745792808c74 2026-07-29 21:34:53 +0000 to 2026-08-04 19:17:33 +0000 - fix(diag): Ensure diagnostic titles work without snippets (rust-lang/cargo#17304) - refactor: Remove unnecessary mut in sources (rust-lang/cargo#17305) - feat(trim-paths): emit unremap files for final artifacts (rust-lang/cargo#17303) - fix: prevent panic when `package.build` is empty (rust-lang/cargo#17268) - Add a suggestion when adding `[lints]` to a workspace to use `[workspace.lints]` instead (rust-lang/cargo#17300) - chore(deps): update embarkstudios/cargo-deny-action action to v2.1.1 (rust-lang/cargo#17291) - refactor: move sysroot lookup to GlobalContext (rust-lang/cargo#17276) - fix(trim-paths): unambiguous and reversible remap rules (rust-lang/cargo#17302) - Avoid parsing unchanged lockfiles (rust-lang/cargo#17301) - Remove unnecessary to_path_buf (rust-lang/cargo#17295) - chore(deps): update cargo-semver-checks to v0.50.0 (rust-lang/cargo#17297) - chore(deps): update actions/checkout action to v6.1.0 (rust-lang/cargo#17290) - Remove unnecessary return at end of functions (rust-lang/cargo#17292) - make __CARGO_TEST_FORCE_ARGFILE available in distributed builds (rust-lang/cargo#17293) - Fix manual_readme lint for lower-priority README files (rust-lang/cargo#17208) - fix(git): make checkout names independent of git config (rust-lang/cargo#17289) - fix(diag): Rename redundant_readme to manual_readme (rust-lang/cargo#17288) - Remove redundant double call .to_string() (rust-lang/cargo#17286) - fix(completions): complete paths for cargo run arguments (rust-lang/cargo#17284) - test(git): exercise multi git revision lockfile (rust-lang/cargo#17279) - add context to lints documentation (rust-lang/cargo#17273) r? ghost

…ark-Simulacrum Add nightly-only support for Cargo unremap trim-paths files in `rust-lldb` Same as rust-lang#160560 but for `rust-lldb`. This PR adds support in `rust-lldb` for the un-remapping file produced by Cargo with `-Ztrim-paths` (rust-lang/cargo#17303). This support is nightly-only, and only activated when `RUST_LLDB_TRIM_PATHS=unstable` is set. The processing is identical to the GDB script, the differences are regarding the interaction with LLDB and the need to setup a background thread.

Rollup merge of #160869 - Urgau:trim-paths-lldb-support, r=Mark-Simulacrum Add nightly-only support for Cargo unremap trim-paths files in `rust-lldb` Same as #160560 but for `rust-lldb`. This PR adds support in `rust-lldb` for the un-remapping file produced by Cargo with `-Ztrim-paths` (rust-lang/cargo#17303). This support is nightly-only, and only activated when `RUST_LLDB_TRIM_PATHS=unstable` is set. The processing is identical to the GDB script, the differences are regarding the interaction with LLDB and the need to setup a background thread.

…acrum Add nightly-only support for Cargo unremap trim-paths files in `rust-lldb` Same as rust-lang/rust#160560 but for `rust-lldb`. This PR adds support in `rust-lldb` for the un-remapping file produced by Cargo with `-Ztrim-paths` (rust-lang/cargo#17303). This support is nightly-only, and only activated when `RUST_LLDB_TRIM_PATHS=unstable` is set. The processing is identical to the GDB script, the differences are regarding the interaction with LLDB and the need to setup a background thread.

rustbot assigned epage Aug 3, 2026

weihanglo force-pushed the unremap-file branch 2 times, most recently from 9e04902 to db2c040 Compare August 3, 2026 11:55

epage reviewed Aug 3, 2026

View reviewed changes

Comment thread src/compiler/build_runner/compilation_files.rs Outdated

epage reviewed Aug 3, 2026

View reviewed changes

Comment thread src/ops/cargo_clean.rs Outdated

epage reviewed Aug 3, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

weihanglo added 2 commits August 3, 2026 21:19

test(trim-paths): cover unremap file scenarios

f97d6b1

refactor(trim-paths): return remap pairs from rules

a14b303

Split remap rule logic into its `(<from>, <to>)` pair as return values. This is meant to be used in unremap file generation.

weihanglo force-pushed the unremap-file branch from db2c040 to 9db4a63 Compare August 4, 2026 01:19

weihanglo force-pushed the unremap-file branch from 9db4a63 to d6fef8a Compare August 4, 2026 01:29

weihanglo added 2 commits August 3, 2026 21:54

docs(trim-paths): emit unremap files for final artifacts

1bfa33c

weihanglo force-pushed the unremap-file branch from d6fef8a to 1bfa33c Compare August 4, 2026 01:54

epage approved these changes Aug 4, 2026

View reviewed changes

epage added this pull request to the merge queue Aug 4, 2026

Merged via the queue into rust-lang:master with commit cafc91b Aug 4, 2026
45 of 58 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 4, 2026

This was referenced Aug 4, 2026

Update cargo submodule rust-lang/rust#160527

Merged

Tracking Issue for trim-paths RFC 3127 #12137

Open

trim-paths: Remap rules for different dependency kinds #13171

Closed

weihanglo deleted the unremap-file branch August 5, 2026 11:25

Urgau mentioned this pull request Aug 5, 2026

Add nightly-only support for Cargo unremap trim-paths files in rust-gdb rust-lang/rust#160560

Merged

rustbot added this to the 1.99.0 milestone Aug 6, 2026

weihanglo added the Z-trim-paths Nightly: path sanitization label Aug 6, 2026

Urgau mentioned this pull request Aug 10, 2026

Add nightly-only support for Cargo unremap trim-paths files in rust-lldb rust-lang/rust#160869

Merged

ranger-ross mentioned this pull request Aug 13, 2026

Remove unremap file when running cargo clean -p in new build-dir layout #17356

Merged

Uh oh!

Uh oh!

Conversation

weihanglo commented Aug 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Note

Uh oh!

rustbot commented Aug 3, 2026

Uh oh!

Uh oh!

epage Aug 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

epage Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

epage Aug 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

epage Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Aug 4, 2026

Uh oh!

Urgau commented Aug 4, 2026

Uh oh!

Urgau commented Aug 4, 2026

Uh oh!

weihanglo commented Aug 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

weihanglo commented Aug 3, 2026 •

edited by rustbot

Loading

epage Aug 3, 2026 •

edited by rustbot

Loading

epage Aug 3, 2026 •

edited by rustbot

Loading