add and document MIRI_LIB_SRC env var to set the source from which Miri builds the standard library
This is just an alias of `XARGO_RUST_SRC`, but avoids exposing how exactly we use xargo.
Provide slightly better notes when tracking a pointer tag
I slapped this in as a sort of advanced println-based debugging when trying to figure out a track-raw-pointers finding in `smallvec`. Perhaps this looks like a good idea to you all?
EDIT: User scenario
Run `MIRIFLAGS=-Ztag-raw-pointers cargo miri test`, get a diagnostic that looks like
```
error: Undefined Behavior: trying to reborrow for SharedReadOnly at alloc99465+0x9, but parent tag <265507> does not have an appropriate item in the borrow stack
```
So now run `MIRIFLAGS=-Ztag-raw-pointers -Zmiri-track-pointer-tag=265507 cargo miri test`
Old:
```
note: tracking was triggered
--> src/lib.rs:822:36
|
822 | vec: NonNull::from(self),
| ^^^^ popped tracked tag for item [SharedReadOnly for <265507>]
```
New:
```
note: tracking was triggered
--> src/lib.rs:822:36
|
822 | vec: NonNull::from(self),
| ^^^^ popped tracked tag for item [SharedReadOnly for <265507>] due to Write access for <265356>
```
So that if a user is now beginning to question their sanity because they don't really understand SB yet, they can then track the tag which caused the parent tag to be removed from the stack to be sure what's going on here:
```
--> src/lib.rs:792:5
|
792 | / pub fn drain<R>(&mut self, range: R) -> Drain<'_, A>
793 | | where
794 | | R: RangeBounds<usize>,
795 | | {
... |
824 | | }
825 | | }
| |_____^ created tag 265356
```
The existing diagnostic can tell you where the tag you'd need was invalidated, but it cannot tell you what and why that tag was invalidated.
intptrcast: Never allocate two objects directly adjecent
When two objects directly follow each other in memory, what is the
provenance of an integer cast to a pointer that points directly between
them? For a zero-size region, it could point into the end of the first
object, or the start of the second.
We can avoid answering this difficult question by simply never
allocating two objects directly beside each other. This fixes some of
the false positives from #1866.
When two objects directly follow each other in memory, what is the
provenance of an integer cast to a pointer that points directly between
them? For a zero-size region, it could point into the end of the first
object, or the start of the second.
We can avoid answering this difficult question by simply never
allocating two objects directly beside each other. This fixes some of
the false positives from #1866.
hack to work around RA quirk
This is a gross hack to work around https://github.com/rust-analyzer/rust-analyzer/issues/10793: calling `cargo-miri/miri` does the same thing as calling `./miri`.
`@oli-obk` this is the best I could come up with... not sure if we want to have this in the repo. I am also okay with carrying `cargo-miri/miri` locally.
test for overflow-checks=off
Strangely, if we call the functions in `std::ops`, we still get the panics. I assume that is because we build the stdlib with `-Cdebug-assertions=on`; probably the magic attribute that makes stdlib functions inherit overflow checks from the calling crate only works one way (namely to enable them when the calling crate asks for them, but not to disable them when the calling crate does not want them).
