Binaries end up containing path to the rust-src component despite --remap-path-prefix

[nagisa]

When the following code is built with rustc with rust-src component available to it, the binary will end up containing the reference to the libstd source in the rustc installation path. This reference is then possibly printed out if this program panics if an error ever occurs.

fn main() {
    std::thread::spawn(|| {
        println!("hello");
    });
}

Compile this program as such:

$ rustc src/main.rs

and inspect the executable with strings:

$ strings ./main | grep lib/rustlib
failed to spawn thread/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libstd/thread/mod.rs
there is no such thing as a relaxed fence/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libcore/macros/mod.rs

Then try to get rid of the source paths with the flag dedicated for exactly this purpose:

$ rustc src/main.rs --remap-path-prefix=/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/=/rustc-src/

and notice that the binary contains the path to the original directory anyway:

$ strings ./main | grep lib/rustlib
failed to spawn thread/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libstd/thread/mod.rs
there is no such thing as a relaxed fence/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libcore/macros/mod.rs

The relevant logic appears to be here:

https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/rmeta/decoder.rs#L1450

However it is not clear to me that this is the right place to introduce more logic to handle --remap-path-prefix.

Version

nightly 2020-06-05

cc @eddyb who appears to have added this logic in #70642

[nagisa]

This is technically a regression, but a unimportant enough one that it should not block a release.

[spastorino]

Assigning P-medium as discussed as part of the Prioritization Working Group process and removing I-prioritize.

[eddyb]

I don't think --remap-path-prefix should remap paths that were already remapped, that feels like a bigger change that is necessary to fix the regression here.

Probably a good way to handle the /rustc/.../ "unmapping"/"devirtualization" is to only expose it to diagnostics, and leave file!() / panic::Location / debuginfo alone (i.e. use /rustc/.../ for it).

Since #72767 we track both paths, so the fix should be relatively simple: use RealFileName's stable_name method (could also rename it to stable_path) instead of local_path in most cases.

However, it looks like everything we want to change and also diagnostics, all go through formatting (i.e. impl std::fmt::Display for FileName) instead of calling any of those methods themselves.

So maybe the fmt::Display impl should have the old behavior, and then we change diagnostics specifically. What's funny is that for the purposes of extracting snippets, local_path is used directly, so we could have source snippets alongside /rustc/... paths, in diagnostics (but I don't think we want that, at least in terms of tooling consuming diagnostics in JSON form).