Repository navigation
remap libstd paths in backtraces for test crates #85463
Description
Activity
@jonas-schievink what version of rustc is this?
This is on
rustc 1.54.0-nightly (881c1ac40 2021-05-08)The most recent nightly seems to work even less:
thread 'frozen::in_par_get_set_cancelation' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', tests/parallel/frozen.rs:64:33 stack backtrace: 0: rust_begin_unwind at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/std/src/panicking.rs:515:5 1: core::panicking::panic_fmt at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/core/src/panicking.rs:92:14 2: core::result::unwrap_failed at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/core/src/result.rs:1355:5 3: core::result::Result<T,E>::unwrap at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/core/src/result.rs:1037:23 4: parallel::frozen::in_par_get_set_cancelation at ./tests/parallel/frozen.rs:64:18 5: parallel::frozen::in_par_get_set_cancelation::{{closure}} at ./tests/parallel/frozen.rs:13:1 6: core::ops::function::FnOnce::call_once at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/core/src/ops/function.rs:227:5 7: core::ops::function::FnOnce::call_once at /rustc/4e3e6db011c5b482d2bef8ba02274657f93b5e0d/library/core/src/ops/function.rs:227:5@jonas-schievink what do you mean? Those look correctly remapped to /rustc/hash to me, were you expecting something else?
Oh I see, you want it to not remap and use the local path.
- changed the title
[-]Path remapping in backtraces is broken[/-][+]Don't remap libstd paths in backtraces for test crates[/+]on May 19, 2021 The(my mistake, the terminology used here wasn't clear to me)/rustc/<hash>path is the non-remapped path. I have the rust-src component installed, so they should be remapped to point there.Reacted by jyn- changed the title
[-]Don't remap libstd paths in backtraces for test crates[/-][+]remap libstd paths in backtraces for test crates[/+]on May 19, 2021 4 remaining items
I guess as an alternative libtest could read a SYSROOT environment variable set by cargo, but that seems kind of hacky.
@jyn514 I'm in the middle of writing an RFC for Cargo that adds a profile setting called
trim-path, which is basically an implementation of #40552 (sanitising every potential absolute paths, like paths to Cargo registry) and is enabled by default for release builds.Prehaps we could make the emission of virtual vs real sysroot paths also dependant on that? It seems a logical thing to do if
trim-pathgets added. This way both test and debug builds will have real paths embedded by default, and can be overriden manually if the user wishes.Reacted by jyn and Aaron HillRFC's here: rust-lang/rfcs#3127
Reacted by jyn- added 3 commits that reference this issue
on Sep 25, 2024
I just got this backtrace when running
RUST_BACKTRACE=1 cargo teston salsa-rs/salsa@bb4b42a:The remapping from
/rustc/...paths to the rust-src component only seems to kick in once here, but I expected it to always work (since the component is installed). Frames 6 and 7 also point to the exact same location, but path remapping still failed for one of them.