Backtrace path usability issue

[lilith]

As an imperfect developer of software that processes imperfect files, backtraces are a... thing. Accurate and navigable backtraces (when using tooling of any kind) are especially helpful.

It would be wonderful to be able to generate backtraces that are relative to my workspace, working directory, or something other than the non-portable /home/user/... or insufficiently specific ./mod.rs, since I have multiple crates. (I'm referring to RUST_BACKTRACE=full and RUST_BACKTRACE=1 respectively).

Perhaps this already exists - "RUST_BACKTRACE" is a difficult search term due to noise.

But if not, I would like to propose "RUST_BACKTRACE_DIR=", which simply truncates the given value from the beginning of any backtrace file path if a match is found. I don't think any allocations would be needed if we're targeting "mycrate/mod.rs" as a result. I assume the formatter could also handle inserting "./" into the output if such a feature was needed (I don't think I do, but others might).

This feature would be helpful not only for WSL users, but also for any remote development or failure analysis work where the build didn't happen on the machine your tooling has access to.

I'm not sure that the current crate-relative behavior for RUST_BACKTRACE=1 is correct when you're building a workspace either, but I think there's little downside to having more specific control over paths.

Code

(from a workspace with multiple crates, including imageflow_core)

RUST_BACKTRACE=1 cargo test

Current output

thread 'test_crop_exif' panicked at 'called `Result::unwrap()` on an `Err` value', imageflow_core/tests/common/mod.rs:374:45
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/panicking.rs:67:14
   2: core::result::unwrap_failed
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/result.rs:1651:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/result.rs:1076:23
   4: visuals::common::ChecksumCtx::bitmap_matches
             at ./tests/common/mod.rs:373:13

Desired output

thread 'test_crop_exif' panicked at 'called `Result::unwrap()` on an `Err` value', imageflow_core/tests/common/mod.rs:374:45
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/panicking.rs:67:14
   2: core::result::unwrap_failed
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/result.rs:1651:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/result.rs:1076:23
   4: visuals::common::ChecksumCtx::bitmap_matches
             at imageflow_core/tests/common/mod.rs:373:13

[xiyuzhai]

Feels like a very important issue. It's really annoying that after so many years this basic feature is not polished as it should be.