Remove miri hack

[taiki-e]

We currently use a hack to avoid rust-lang/rust#69488 and to make sure that Miri errors for atomic load/store of integers containing uninitialized bytes (which is probably not a problem and uncharted territory at best 1 2 3, and can be detected by -Zmiri-check-number-validity 4), do not mask Miri errors for the use of uninitialized bytes (which is definitely a problem).

atomic-memcpy/src/lib.rs

Lines 426 to 450 in 3507fef

	// HACK: Miri cannot track uninitialized bytes on a per byte basis for
	// partially initialized scalars: https://github.com/rust-lang/rust/issues/69488
	//
	// This hack allows miri to properly track the use of uninitialized
	// bytes. See also tests/uninit.rs that is a test to check if
	// valgrind/sanitizer/miri can properly detect the use of uninitialized
	// bytes.
	//
	// Note: With or without this hack, atomic load/store of integers
	// containing uninitialized bytes is technically an undefined behavior.
	// The only purpose of this hack is to make sure that Miri errors for
	// atomic load/store of integers containing uninitialized bytes
	// (which is probably not a problem and uncharted territory at best [1] [2] [3],
	// and can be detected by `-Zmiri-check-number-validity` [4]),
	// do not mask Miri errors for the use of uninitialized bytes (which is definitely a problem).
	// See also tests/padding.rs.
	//
	// [1] https://github.com/crossbeam-rs/crossbeam/issues/315
	// [2] https://github.com/rust-lang/unsafe-code-guidelines/issues/158
	// [3] https://github.com/rust-lang/unsafe-code-guidelines/issues/71
	// [4] https://github.com/rust-lang/miri/pull/1904
	//
	// rust-lang/rust#69488 affects only CTFE(compile-time function evaluation)/Miri
	// and atomic operations cannot be called in const context, so our code
	// is only affected in the case of cfg(miri).

However, this actually causes another "unsupported operation" Miri error.

error: unsupported operation: unable to turn pointer into raw bytes
   --> /Users/taiki/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:701:9
    |
701 |         copy_nonoverlapping(src, tmp.as_mut_ptr(), 1);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unable to turn pointer into raw bytes
    |
    = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support

[taiki-e]

bors r+

[bors]

Build succeeded:

• ci

[RalfJung]

Just noticed this by coincidence, and I am trying to understand what happens here.

If I understand correctly, this code effectively performs a copy at a type like u64, and due to rust-lang/rust#69488, that "inflates" uninit which causes problems. However, if that is the case, it will cause problems even without -Zmiri-check-number-validity, the problems are just slightly delayed: if x is uninit, x = 1 will fail in Miri even without that flag.

Moreover, arguably, this is not just a Miri limitation, it actually accurately reflects the reference. I have ideas for fixing rust-lang/rust#69488; they will not fix the problem described here.

Finally, if we start emitting noundef flags for LLVM on our integer types (which the reference says we can), then the approach in this crate will be problematic even if we ignore Rust UB and consider only LLVM UB.

So, I agree that AtomicMaybeUninit is the solution -- but until we have that, the problem isn't just a limitation in Miri, it is a limitation in Rust generally.

[taiki-e]

Thanks. I agree that the current readme is incorrect. (Filed #5 to fix readme)