Fix attempted to read from stolen value

[W95Psp]

The frontend browses items of a crate in an order that causes this bug.
Some data in the Rust compiler is kept in a Steal, which is basically a box whose content can be stolen, that is pulled out of the memory (rustc uses arenas)

Thus, the order in which we browse the crate to export every item matters: sometimes I inspect things that happens to be stolen before because of some previous inspections.
This is particularly true for constants, it seems.

Status: mostly fixed

• @geonnave's bug (Fix attempted to read from stolen value #27 (comment)) is fixed
• @franziskuskiefer's bug (Fix attempted to read from stolen value #27 (comment)) is fixed

However, I tried Hax on core, and I get new stolen stuff. Thus, there exists some scenarios in which this still fails.

[geonnave]

For the record (context from #99):

• this issue also affects translation of the edhoc-rs crate into fstar.
• in fstar generation fails with Unimplemented on array! macro #99 there is a How to reproduce section, that could be validated against once this issue is addressed.

[franziskuskiefer]

Another code snippet that panics

#[repr(u16)]
pub enum ProtocolVersion {
    Mls10 = 1,
}

impl ProtocolVersion {
    #[allow(non_upper_case_globals)]
    fn tls_deserialize(bytes: &[u8]) -> core::result::Result<(Self, &[u8]), tls_codec::Error> {
        const __TLS_CODEC_Mls10: u16 = ProtocolVersion::Mls10 as u16;
        let (discriminant, remainder) =
            <u16 as tls_codec::DeserializeBytes>::tls_deserialize(bytes)?;
        match discriminant {
            __TLS_CODEC_Mls10 => {
                let result = ProtocolVersion::Mls10 {};
                Ok((result, remainder))
            }
            _ => Err(tls_codec::Error::UnknownValue(discriminant.into())),
        }
    }
}

[W95Psp]

Another stealing bug (from issue #474):

hax/tests/rust-ast/src/lib.rs

Lines 14 to 20 in aa14fb1

	// error: The THIR body of item DefId(0:7 ~ rust_ast[d581]::main::_::{constant#1}) was stolen.
	const _MY_CONST: bool = true;
	pub fn main() {
	const _: [(); 1] = [(); _MY_CONST as usize];
	}

Originally posted by @franziskuskiefer in #474 (comment)

Open this code snippet in the playground

Status: works OK in 8ab62258df ✅

[franziskuskiefer]

It looks like the two examples here are not triggering the stealing bug anymore.

[Nadrieril]

My current understanding of stealing insofar as it affects us:

• THIR is stolen to construct the built MIR;
• the built MIR is stolen to construct the optimized or ctfe MIRs;
• optimized/ctfe MIR is required to evaluate constants, which happens if a constant shows up as a const generic argument, as a pattern, inside another evaluated constant, inside a MIR body that is being optimized, and likely other cases.

Hence even translating a type may steal a THIR/MIR body.

[W95Psp]

Yes, exactly, that's what is happening :(
Thus it's not even clear we can come up with a visit order of items that would avoid stealing issues...

[Nadrieril]

If we could detect whether a value is already stolen, we could fallback to the optimized MIR/evaluated value for constants.

[Nadrieril]

Opened rust-lang/rust#128815

[W95Psp]

reproducer for a stealing bug with cargo hax into -k mir-built: https://hax-playground.cryspen.com/#json+mir/a339b28377/gist=6630144c4732a2bd55ef8ded02b30ef6

(I haven't shown you the playground yet @Nadrieril, right? 😃 'right click > show MIR' on a rust subexpression might be interesting to you :D)

[Nadrieril]

You should now be able to fix all MIR stealing bugs by using the optimized_mir when tcx.mir_built().is_stolen(). For THIR bodies I don't think there's a good solution.