Closed
Description
Spawned off of #64507
I tried this code:
% rustup default
stable-aarch64-apple-darwin (default)
% rustup component list | grep installed
cargo-aarch64-apple-darwin (installed)
clippy-aarch64-apple-darwin (installed)
rust-src (installed)
rust-std-aarch64-apple-darwin (installed)
rust-std-wasm32-unknown-unknown (installed)
rustc-aarch64-apple-darwin (installed)
rustfmt-aarch64-apple-darwin (installed)
% cat map-panic.rs
fn main() {
let _x: Option<String> = Some(42u32).map(|_| panic!("hello world"));
}
% rustc -vV
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: aarch64-apple-darwin
release: 1.64.0
LLVM version: 14.0.6
% rustc -g map-panic.rs
% RUST_BACKTRACE=1 ./map-panic
thread 'main' panicked at 'hello world', map-panic.rs:2:50
stack backtrace:
0: std::panicking::begin_panic
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:616:12
1: map_panic::main::{{closure}}
at ./map-panic.rs:2:50
2: core::option::Option<T>::map
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:929:29
3: map_panic::main
at ./map-panic.rs:2:30
4: core::ops::function::FnOnce::call_once
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
I expected to see this happen: I expected the /rustc/$hash
to be mapped to the local paths in the installed rust-src
component, rather than being left as raw /rustc/$hash
Instead, this happened: /rustc/$hash
is showing up in the output.
Meta
rustc --version --verbose
:
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: aarch64-apple-darwin
release: 1.64.0
LLVM version: 14.0.6
Activity
pnkfelix commentedon Dec 19, 2022
see related discussion from wg-debugging triage here
pnkfelix commentedon Dec 19, 2022
in particular, @bjorn3 pointed out that that this remapping should be happening if one has the
rust-src
component installed, and that the code doing the remapping should be executed here:rust/compiler/rustc_metadata/src/rmeta/decoder.rs
Lines 1419 to 1493 in 4653c93
and there is corresponding code in bootstrap dist code:
rust/src/bootstrap/dist.rs
Lines 876 to 903 in 4653c93
There's some useful
debug!
statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...lqd commentedon Dec 19, 2022
But this is currently a remapping at runtime only when using
-Zsimulate-remapped-rust-src-base
like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they setCFG_VIRTUAL_RUST_SOURCE_BASE_DIR
.bjorn3 commentedon Dec 19, 2022
CFG_VIRTUAL_RUST_SOURCE_BASE_DIR
is/rustc/$hash
, right? That is what it is mapped from, not what it is mapped to.lqd commentedon Dec 19, 2022
Its and
-Zsimulate-remapped-rust-src-base
's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwisevirtual_rust_source_base_dir
would be "empty" andtry_to_translate_virtual_to_real
would be a no-op), so I may be missing how this could already remap to the localrustc-src
component according to Felix's comment above ?ehuss commentedon Dec 20, 2022
I believe these are not being remapped on purpose (based on #83813 (comment)). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in #85463 (and #73167 and #83813 to some degree). There's also concerns about how it can affect binary size (#82188). rust-lang/rfcs#3127 also discusses it some.
Nemo157 commentedon Nov 10, 2023
These paths are also not being remapped even when explicitly requested with
--remap-path-prefix=/rustc/<hash>=...
Auto merge of rust-lang#118149 - cbeuw:rfc3127-sysroot, r=b-naber
13 remaining items