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).
rename track-raw-pointers flag to tag-raw-pointers
The old flag name sounds too similar to `-Zmiri-track-pointer-tag`, which is a totally different kind of 'tracking'. This has lead to confusion in https://github.com/rust-lang/miri/issues/1907.
tweak cron job time
15:00 UTC is 16:00 in Europe and 10:00 on the US East Coast (during winter time, and 1h later during summer time), so a good time in both places to see the email and react quickly. No need to run this in the middle of the night if nobody will fix the problem anyway.
Move it 5min past the full hour to avoid what is probably a rush of cronjobs on the full hour.
