Binaries end up containing path to the rust-src component despite `--remap-path-prefix`
nagisa opened this issue · comments
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
This is technically a regression, but a unimportant enough one that it should not block a release.
Assigning P-medium
as discussed as part of the Prioritization Working Group process and removing I-prioritize
.
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).