Rust references allow the compiler to assume that the data behind them is valid. One way in which rustc currently uses this is to tag the associated pointers with LLVM's dereferencable attibute, which allows the latter to prefetch from them to its heart's content. This kind of smart optimization should not be allowed before objects are exhumed, as it can lead to undefined behavior like LLVM following dangling pointers and segfaulting the program.
Therefore, I think exhume should not take its target object as a Rust reference, but as a NonNull pointer, which provides no guarantee of target data validity to rustc and therefore doesn't allow the compiler to muck around with it.
Rust references allow the compiler to assume that the data behind them is valid. One way in which
rustccurrently uses this is to tag the associated pointers with LLVM'sdereferencableattibute, which allows the latter to prefetch from them to its heart's content. This kind of smart optimization should not be allowed before objects are exhumed, as it can lead to undefined behavior like LLVM following dangling pointers and segfaulting the program.Therefore, I think
exhumeshould not take its target object as a Rust reference, but as aNonNullpointer, which provides no guarantee of target data validity to rustc and therefore doesn't allow the compiler to muck around with it.