fix(trim-paths): custom workspace-relative member paths remap

[weihanglo]

What does this PR try to resolve?

This adds the missing rustc bootstrap custom remap prefix
for packages relative to the working directory.

Cargo's workspace remap rule was pretty simple:
everything under the working directory¹ becomes relative to the working directory
(like strip_prefix(root)).

For supporting rustc bootstrap remaps (#17309),
we added specific env var __CARGO_RUSTC_BOOTSTRAP_WS_REMAP
to set custom prefix for workspace remap rule.
That covers absolute paths starting with `

Unfortunately,
it didn't cover paths already relative to the working directory.
The reason is that
Cargo already passes workspace member paths relative to the working directory.
For example,
the path rustc saw was already relative like library/std/src/lib.rs.
The path never matches the remap prefix <ws-root>
so cannot be remapped by Cargo's -Ztrim-paths.

Below are incorrect and expected diagnostics:

    note: required by a bound in `std::fs::read_to_string`
     --> library/std/src/fs.rs:383:0               (before this PR, wrong)
     --> /rustc/<sha>/library/std/src/fs.rs:383:0  (expected)

This PR extends __CARGO_RUSTC_BOOTSTRAP_WS_REMAP
to additionally add a remap rule for everything relative to workspace.
The new remap rule joisn the prefix with the relative path,
so library/std/src/lib.rs becomes /<custom-prefix>/library/std/src/lib.rs.

Full comparsion:

rule	old handwritten remap	-Ztrim-paths before this	-Ztrim-paths after this
ws	<root> -> /rustc/<sha>	<root> -> /rustc/<sha>	<root> → /rustc/<sha>
ws relative	library/ -> /rustc/<sha>/library/	library/ -> library/ (no remap at all)	library/ -> /rustc/<sha>/library

See rust-lang/rust#161049 (comment)

Part of #17309

How to test and review this PR?

cc @Urgau

🤖 LLM disclosure: Used for verifying it actually works with rustc bootstrap, which has been signed off on rust-lang/rust side (rust-lang/rust#161049).

Footnotes

1. by default it is Cargo workspace root but rustc bootstrap use -Zroot-dir to set the working directory always to the repo root (or checkout out, whatever you like, it is the directory that has the x.py) ↩

[rustbot]

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

[weihanglo]

I don't particularly like this, but seems like inevitable as we already opened the __CARGO_RUSTC_BOOTSTRAP_WS_REMAP door and this is an artifact of that. The other direction is we remove the __CARGO_RUSTC_BOOTSTRAP_WS_REMAP. However, that means rustc bootstrap need to do it again and perhaps for both rustc code and build.rs remaps.

[Urgau]

This isn't needed for normal cases
because relative member paths are exactly what users want.

I'm not certain about that. I would expect users who distribute binaries and libraries to only want remapped paths, not a mix of absolute remapped paths but relative paths are not.

[Urgau]

For example if I distribute a Rust software with -Ztrim-paths=object and it crashes, with the current behavior the backtrace may contain both absolute remapped paths and relative paths, that doesn't seems great as that means that users will need to have two code paths for symbolizing the stacktrace back to the individual files instead of only one.

Like is the case with rustc, not remapping the relative paths would mean that we would need to have a second system to "unremap"/handle relative paths.

[weihanglo]

I see. So it is not just an extra prefix that a symbolication pipeline or symbol server can handle with one more entry. It is a dual mode (relative paths vs. virtual prefix) that consumers need to deal with separately.

My original idea of keeping it relative is for an easier debugging experience that people mostly debug their own application code. Without a virtual prefix for local there is nothing to configure in the debugger.

Anyway, valid point. Let's record it as an unresolved question and ask users during the call for testing.

[epage]

I'm finding this PR confusing. This is for rustc bootstrap's special mode but I'm not seeing how the new code path ties to it.

I suspect this is too general, making that relationship unclear.

I also feel like the descriptions here and the PR assume enough knowledge that the intended effect is unclear.

View changes since the review

[weihanglo]

Thanks for the review! Updated the PR description with more contexts. Let me know if it is good enough.

For this feature, I intentionally made it a bit more general, as it may become an (unstable) config for people to customize it. See Urague's comment above #17366 (comment).