Miri diagnostics: Show location of creation/invalidation in own code

[Noratrieb]

I'm in a crate (rustc_arena) where some UB was found. The created/invalidated spans point at core, since it's in the same workspace.

Backtrace

test tests::bench_copy ... error: Undefined Behavior: attempting a write access using <210850> at alloc86975[0x0], but that tag does not exist in the borrow stack for this location
    --> /home/nilsh/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1342:9
     |
1342 |         copy_nonoverlapping(&src as *const T, dst, 1);
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |         |
     |         attempting a write access using <210850> at alloc86975[0x0], but that tag does not exist in the borrow stack for this location
     |         this error occurs as part of an access at alloc86975[0x0..0xc]
     |
     = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental
     = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <210850> was created by a retag at offsets [0x0..0xffc]
    --> /home/nilsh/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:507:9
     |
507  |         self as *mut [T] as *mut T
     |         ^^^^
help: <210850> was later invalidated at offsets [0x0..0xffc]
    --> compiler/rustc_arena/src/lib.rs:90:48
     |
90   |         MaybeUninit::slice_as_mut_ptr(unsafe { &mut *self.storage.as_mut() })
     |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^

```

It would be useful to be able to make it point to the actual offending calls in rustc_arena, since the actual bug was there.

See here: rust-lang/rust#97711

[RalfJung]

Do you have a concrete example / testcase for this? That would help make the discussion less abstract.

Cc @saethlin

[Noratrieb]

I have updated the issue with better info

[saethlin]

I think the problem here is that core counts as a local crate. Really, hacking on rust-lang/rust is going to be a bear because of this. It currently has 121 crates, so a huge fraction of all code in the build counts as a local crate which is approximately the opposite of what the local crate filtering is supposed to do.

At the moment, the only thing I can think of to do for this is to give the end user more control over the local crate selection. But they might as well just use -Zmiri-track-pointer-tag if they're going to have to run the tool twice anyway. I'm not really sure what a better default would be. For sure using the local crate is the wrong decision because that goes wrong for tests.

[RalfJung]

Oh, this is rustc_arena in the rustc workspace? Yeah that would explain this...

[RalfJung]

We could hard-code core, alloc, and std as never being local? 🤷

[Noratrieb]

Maybe it would make sense to have a flag like -Zmiri-diagnostic-exclude-crates (or a better name) to mark these crates as non-local even if they are. But I'm not sure whether adding more and more flags actually solves issues or only creates new ones (people not knowing about the flags).

[Noratrieb]

I think there is a need for a kind of miri-walkthrough that explains the most important flags and ways to use miri in a nice tutorial. I might take a look at that.

[RalfJung]

Yes, a "Miri book" would probably make a lot of sense. :-)

[RalfJung]

At least the particular span slice/mod.rs:507:9 could possibly be fixed by marking slice.as_mut_ptr as track_caller and having the Stacked Borrows diagnostic code respect that attribute.