exclude mutable references to !Unpin types from uniqueness guarantees
This basically works around https://github.com/rust-lang/unsafe-code-guidelines/issues/148 by not requiring uniqueness any more for mutable references to self-referential generators. That corresponds to [the same work-around that was applied in rustc itself](b815532674/compiler/rustc_middle/src/ty/layout.rs (L2482)).
I am not entirely sure if this is a good idea since it might hide too many errors in case types are "accidentally" `!Unpin`. OTOH, our test suite still passes, and to my knowledge the vast majority of types is `Unpin`. (`place.layout.ty` is monomorphic, we should always exactly know which type this is.)
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.
