regression: transmute_copy validates sizing

[Mark-Simulacrum]

transmute_copy now validates reasonable sizes and panics if not as of #98839, this causes some breakage (detected at the time in #98839 (comment)).

Mostly filing this issue to make sure we add a release notes compat note about this, but I don't expect us to do anything further. Nominating for T-libs-api, though, mostly just for awareness.

cc @tmandry / @joshtriplett -- let's make sure this makes it into 1.64 release notes

[estebank]

I believe this is the same as #99923

Edit: I meant "the same category as".

[Mark-Simulacrum]

Seems like a much easier issue to explain, at least - not sure I would quite call it "same as" pointer/integer transmutes :) Though the overall effect of breaking unsafe code seems quite similar.

[RalfJung]

I believe this is the same as #99923

The issues seem entirely unrelated to me, in which sense are they "the same"?

[RalfJung]

Or did you mean they are broadly the same category, being related to UB detection? But even then, #99923 is about compile-time UB, and this here is primarily about run-time UB, and those are very different in how we treat them.

Seems like a much easier issue to explain, at least - not sure I would quite call it "same as" pointer/integer transmutes :)

The easiest justification for the panic is "transmute_copy has a safety precondition that U, the return type, is not larger than T, the input type, this can be checked with zero runtime cost, so a panic was inserted in the UB case". As in, "it's UB because we wrote that it was UB" (it would be an out of bounds read internally, is the main reason it's marked as UB)

Maybe also mention RUST_BACKTRACE=1 since the panic location will point to the stdlib internals, not the caller. As I understand it, track_caller would make it non-zero cost for a function that's UB to panic anyways, so I didn't add it. (It does mean if you don't have gdb or backtraces, you're going to have a fun time finding the panic. We do indicate what the caller did wrong, but not where the caller is).

[RalfJung]

Yeah, we could have a cfg_attr(debug_assertions, track_caller) but that would only help once we have a good system for letting people use a debug build of the standard library...