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

[weihanglo]

What does this PR try to resolve?

This is effectively library/=<to>/library
and compiler/=<to>/compiler in rustc bootstrap,
when __CARGO_RUSTC_BOOTSTRAP_WS_REMAP is set.

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

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).

[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.