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.)
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.
This commit adds a `-Zmiri-check-number-initialization` flag to check
that integers and floats are initialized.
This commit also changes some shims to write at type `MaybeUninit<...>`
in order to prevent spurious errors from the uninit check.
add support for `#[global_allocator]`
This PR adds support for custom global allocators. Unfortunately, the code given in #1207 still causes errors when used with box. I believe this is because Box is special-cased in miri and stacked borrows.
Previously the command line string would have been incorrectly constructed if argv[0] contained a doublequote (`"`) or ended in a trailing backslash (`\`). This is a very rare edge case because, by convention, argv[0] is the path to the application and Windows file names cannot contain doublequotes.
Fixes#1881
add support for `#[start]`
This PR adds support for the `#[start]` attribute and fixes#1825.
It also renames `eval_main` to `eval_entry` to reflect that it can evaluate any entry function.
Add support for the `volatile_set_memory` intrinsic
Add support for the unstable `volatile_set_memory` intrinsic
(Runtime behaviour and soundness requirements for `volatile_set_memory` are identical to those of `write_bytes`, so supporting this intrinsic is trivial.)
also ignore 'thread leaks' with -Zmiri-ignore-leaks
This is a step towards https://github.com/rust-lang/miri/issues/1371. The remaining hard part would be supporting checking for memory leaks when there are threads still running. For now we elegantly avoid this problem by using the same flag to control both of these checks. :)
