Auto merge of #113892 - RalfJung:uninit-undef-poison, r=wesleywiser
clarify MIR uninit vs LLVM undef/poison In [this LLVM discussion](https://discourse.llvm.org/t/rfc-load-instruction-uninitialized-memory-semantics/67481) I learned that mapping our uninitialized memory in MIR to poison in LLVM would be quite problematic due to the lack of a byte type. I am not sure where to write down this insight but this seems like a reasonable start.
This commit is contained in:
commit
d908a5b08e
2 changed files with 7 additions and 1 deletions
|
@ -5,7 +5,13 @@ use rustc_target::abi;
|
|||
pub trait ConstMethods<'tcx>: BackendTypes {
|
||||
// Constant constructors
|
||||
fn const_null(&self, t: Self::Type) -> Self::Value;
|
||||
/// Generate an uninitialized value (matching uninitialized memory in MIR).
|
||||
/// Whether memory is initialized or not is tracked byte-for-byte.
|
||||
fn const_undef(&self, t: Self::Type) -> Self::Value;
|
||||
/// Generate a fake value. Poison always affects the entire value, even if just a single byte is
|
||||
/// poison. This can only be used in codepaths that are already UB, i.e., UB-free Rust code
|
||||
/// (including code that e.g. copies uninit memory with `MaybeUninit`) can never encounter a
|
||||
/// poison value.
|
||||
fn const_poison(&self, t: Self::Type) -> Self::Value;
|
||||
fn const_int(&self, t: Self::Type, i: i64) -> Self::Value;
|
||||
fn const_uint(&self, t: Self::Type, i: u64) -> Self::Value;
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue