CTFE: throw unsupported error when partially overwriting a pointer

[RalfJung]

Currently, during CTFE, when a write to memory would overwrite parts of a pointer, we make the remaining parts of that pointer "uninitialized". This is probably not what users expect, so if this ever happens they will be quite confused about why some of the data just vanishes for seemingly no good reason.
So I propose we change this to abort CTFE when that happens, to at last avoid silently doing the wrong thing.
Cc #87184

Our CTFE test suite still seems to pass. However, we should probably crater this, and I want to do some tests with Miri as well.

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

r? @oli-obk

[RalfJung]

Ah turns out Miri really needs this:

error: unsupported operation: unable to overwrite parts of a pointer in memory at alloc1390
   --> /home/r/src/rust/rustc/library/std/src/panicking.rs:401:13
    |
401 |             data.r = ManuallyDrop::new(f());
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unable to overwrite parts of a pointer in memory at alloc1390
    |
    = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support

    = note: inside `std::panicking::try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/r/src/rust/rustc/library/std/src/panicking.rs:401:13
    = note: inside `std::panicking::try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>` at /home/r/src/rust/rustc/library/std/src/panicking.rs:365:19

[RalfJung]

@bors try

[bors]

⌛ Trying commit 4725c8543fc218bcafef8c60a9f397019bc5e1aa with merge 3e59a8c2f14152ccc92a6c079f592dc2dc6fa93f...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3e59a8c2f14152ccc92a6c079f592dc2dc6fa93f (3e59a8c2f14152ccc92a6c079f592dc2dc6fa93f)

[RalfJung]

@craterbot check

[craterbot]

👌 Experiment pr-87248 created and queued.
🤖 Automatically detected try build 3e59a8c2f14152ccc92a6c079f592dc2dc6fa93f
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-87248 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-87248 is completed!
📊 10 regressed and 6 fixed (173576 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[oli-obk]

All of the regressions are spurious (some python network error and some file not found)

[RalfJung]

Nice, that's what I hoped for. :)

So how do we proceed here -- what are your thoughts on this PR, @oli-obk?
(I sure need to add a test before landing.)

[oli-obk]

I like how this allows us to experiment on miri first!

lgtm modulo some tests

[RalfJung]

Added a test, please have a look. :)

[oli-obk]

@bors r+

[bors]

📌 Commit 2a9b44d has been approved by oli-obk

[bors]

⌛ Testing commit 2a9b44d with merge 3227e35...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 3227e35 to master...

[rust-highfive]

📣 Toolstate changed by #87248!

Tested on commit 3227e35.
Direct link to PR: #87248

💔 miri on windows: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk).
💔 miri on linux: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk).