Stacked Borrows: don't read from memory during retagging
Currently, retagging of a shared reference tries real hard to find the `UnsafeCell` and mark everything else as frozen. We even read enum discriminants to figure out the variant and determine if there is an `UnsafeCell` in there or not.
Unfortunately, that leads to some very hard to analyze behavior: during retagging, we do read accesses, which are subject to the rules of Stacked Borrows and the existing tags! My head hurts when I try to think about this. It's just too recursive.
This PR simplifies the semantics by treating enums like unions: if any variant has an `UnsafeCell`, the entire thing behaves like an `UnsafeCell`. This means retagging no longer has to read from memory, the way it affects the stack is entirely determined by the type.
test that build scripts do not run in Miri
@elichai reported something that sounded a lot like build script running in Miri. But as this test shows, build scripts are not run by Miri, they are run normally.
@elichai are you sure the [env var usage you were referring to](https://github.com/rust-lang/miri/issues/641#issuecomment-524989482) was only in a build script? Those shouldn't be affected by Miri flags at all. Is your code available somewhere so that I can try to reproduce?
Write name and value for each env var
In order to res0lve https://github.com/rust-lang/miri/issues/756 is necessary to have the whole `"NAME=VALUE"` sequence of bytes written into memory instead of just the value.
This change does not affect the interface of the `shim::envs::EnvVars` type in any way.
r? @RalfJung @oli-obk
explicitly enable getrandom/std feature
This seems to be what rand_core does, and then we need to do it as well or else the rustc feature checker complains.
change flag name: enable-communication -> disable-isolation
r? @oli-obk -- I think this is a better name for the flag but it is still somewhat clumsy. Suggestions?
Use host's rng when communication is enabled
This uses the host's randomness when the communication enabled flag is used. I am not sure about the error handling. I was thinking about fallbacking to `rand` if `getrandom` fails and also print something so the user knows miri is not using the host's rng because it failed. Let me know what you think.
Related issue: https://github.com/rust-lang/miri/issues/800.
r? @RalfJung @oli-obk
