trim-paths mixes forward and backslashes in backtrace when built on WIndows

[mlaota]

Problem

trim-paths mixes forward and backslashes in backtrace when building on Windows

Expectation

Backtrace contains valid paths

Actual

Backtrace contains invalid paths mixing forward and backslashes (e.g. /path/to\file)

Steps

1. On a Windows machine, run command cargo new reproduce-trim-paths-mixed-slash
2. Paste the following in the generated Cargo.toml:

cargo-features = ["trim-paths"]

[package]
name = "reproduce-trim-paths-mixed-slash"
version = "0.1.0"
edition = "2021"

[profile.release]
debug = true
trim-paths = "all"

3. Paste the following in the geenrated src/main.rs:

fn main() {
    panic!("PANICKING");
}

4. Run command cargo build --release
5. Run command RUST_BACKTRACE=1 ./target/release/reproduce-trim-paths-mixed-slash.exe (note: although I'm using Windows, my application build is Linux x86_64, and the path issue is present there too).

Output:

thread 'main' panicked at src/main.rs:2:5:
PANICKING
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\panicking.rs:662
   1: core::panicking::panic_fmt
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/core\src\panicking.rs:74
   2: __ImageBase
   3: __ImageBase
   4: __ImageBase
   5: std::rt::lang_start_internal::closure$2
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\rt.rs:143
   6: std::panicking::try::do_call
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\panicking.rs:554
   7: std::panicking::try
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\panicking.rs:518
   8: std::panic::catch_unwind
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\panic.rs:345
   9: std::rt::lang_start_internal
             at /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e\library/std\src\rt.rs:143
  10: main
  11: invoke_main
             at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  12: __scrt_common_main_seh
             at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  13: BaseThreadInitThunk
  14: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Possible Solution(s)

Use consistent slashes in all paths

Notes

No response

Version

cargo 1.82.0-nightly (0d8d22f83 2024-08-08)
release: 1.82.0-nightly
commit-hash: 0d8d22f83b066503f6b2b755925197e959e58b4f
commit-date: 2024-08-08
host: x86_64-pc-windows-msvc
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:Schannel)
os: Windows 10.0.22631 (Windows 11 Core) [64-bit]

[weihanglo]

Thanks for the report. I am not sure if rustc starts using -Ztrim-paths to sanitize backtrace. Could you pick a toolchain version prior to -Ztrim-paths and try if it can be reproduced? 1.74 should be sufficient.

Besides, I am not sure if we want to have backslashes for /rustc/80eb5a8e910e5185d47cdefe3732d839c78a5e7e. While it is visual consistent if using the same kind of slashes, /rustc/<hash> is in fact just a placeholder not an actual file system path, so shouldn't have impact more than visual pleasing. Doing it that might be harder for user/tool to find-and-replace the prefix. (I am not sure about the acutal use case though)

cc @michaelwoerister Kindly asking for your opinions :)