]> git.lizzy.rs Git - rust.git/commit - src/tools/miri
Rollup merge of #98839 - 5225225:assert_transmute_copy_size, r=thomcc
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>
Mon, 18 Jul 2022 15:44:42 +0000 (21:14 +0530)
committerGitHub <noreply@github.com>
Mon, 18 Jul 2022 15:44:42 +0000 (21:14 +0530)
commit5ccdf1f6f7651001e3b15f48c6f2e5d0b56accf2
treed315a2bd57df63d802a1eafc64ef07d98c2fb765
parent9ed0bf9f2bd63933785fb8a380c177d2d70e88ec
parent5f5ca889589c24a12864329c027db431adbc7fae
Rollup merge of #98839 - 5225225:assert_transmute_copy_size, r=thomcc

Add assertion that `transmute_copy`'s U is not larger than T

This is called out as a safety requirement in the docs, but because knowing this can be done at compile time and constant folded (just like the `align_of` branch is removed), we can just panic here.

I've looked at the asm (using `cargo-asm`) of a function that both is correct and incorrect, and the panic is completely removed, or is unconditional, without needing build-std.

I don't expect this to cause much breakage in the wild. I scanned through https://miri.saethlin.dev/ub for issues that would look like this (error: Undefined Behavior: memory access failed: alloc1768 has size 1, so pointer to 8 bytes starting at offset 0 is out-of-bounds), but couldn't find any.

That doesn't rule out it happening in crates tested that fail earlier for some other reason, though, but it indicates that doing this is rare, if it happens at all. A crater run for this would need to be build and test, since this is a runtime thing.

Also added a few more transmute_copy tests.