Span of local crate leaks into tcx.optimized_mir of other crate

[bjorn3]

$ MIRI_SYSROOT=/home/bjorn/.cache/miri/HOST cargo run -- core mir "DefId(1/0:20381 ~ core[eddd]::char[0]::convert[0]::{{impl}}[9]::fmt[0])"
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/rlib_view core mir 'DefId(1/0:20381 ~ core[eddd]::char[0]::convert[0]::{{impl}}[9]::fmt[0])'`
Reading rlib core
Rust args: ["core", "/some_nonexistent_dummy_path", "--sysroot", "/home/bjorn/.cache/miri/HOST", "-Cpanic=abort"]
error: `#[panic_handler]` function required, but not found

mir for <core::char::ParseCharError as core::fmt::Debug>::fmt:

[...]
        StorageLive(_4);                 // bb0[5]: scope 1 at /some_nonexistent_dummy_path:1:1: 1:1
[...]
        StorageDead(_7);                 // bb1[3]: scope 1 at /some_nonexistent_dummy_path:1:1: 1:1
[...]

[bjorn3]

Sysroot has been compiled using cargo miri setup to get -Zalways-encode-mir set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:

$ MIRI_SYSROOT=/home/bjorn/.cache/miri/HOST cargo run -- core symbols |& head
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/rlib_view core symbols`
Reading rlib core
Rust args: ["core", "/some_nonexistent_dummy_path", "--sysroot", "/home/bjorn/.cache/miri/HOST", "-Cpanic=abort"]
error: `#[panic_handler]` function required, but not found


Exported symbols:
    Rust <core::char::ParseCharError as core::fmt::Debug>::fmt (DefId(1/0:20381 ~ core[eddd]::char[0]::convert[0]::{{impl}}[9]::fmt[0]))
    Rust core::fmt::Formatter::alternate (DefId(1/0:4257 ~ core[eddd]::fmt[0]::{{impl}}[6]::alternate[0]))
[1]    22404 illegal hardware instruction  MIRI_SYSROOT=/home/bjorn/.cache/miri/HOST cargo run -- core symbols 2>&1 | 
       22405 done                          head

[bjorn3]

I used https://github.com/bjorn3/rust_read_rlib to read the mir.

[bjorn3]

I think these are DUMMY_SP and printed as /some_nonexistent_dummy_path:1:1: 1:1. If so it would be less confusing if the debug impl of DUMMY_SP would say DUMMY_SP or something like that instead.

[oli-obk]

I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for DUMMY_SP, but without a test for that I'm not sure how to test it