New test for loading a pointer as part of a read

[oli-obk]

@eddyb would like

use std::mem::transmute;
fn main() {
    for &my_bool in &[true, false] {
        unsafe {
            println!("{}", transmute::<_, &str>(!-(my_bool as i128) & transmute::<_, i128>("false !") | -(my_bool as i128) & transmute::<_, i128>("true !")));
        }
    }
}

to be in the miri test suite.

The diagnostic is also wrong, it's actually that we want to put two pointers into a single i128 immediate value.

[RalfJung]

Yeah sure, we can add that.

For the error message, I guess it's the other way around here -- encountered pointer in part of a read. ;) Not sure how to best word it though.

[RalfJung]

But also, I wouldn't mind an explanation of what the point of this is.^^ !-(my_bool as i128) & looks like gibberish, what is going on there...?

[RalfJung]

Most of the code in this test is actually irrelevant; transmute::<_, i128>("false !") already triggers the error. So I am not sure what this is supposed to test, but the !-(my_bool as i128) & part mostly obfuscates what is going on.

[eddyb]

Really sorry about the confusion!

(~-cond & a) | (-cond & b) is "standard" (bitwise) branchless if-else/"select". but:

• ~ is ! in Rust
• Rust also needs explicit casts from bool

The weird -cond that looks like obfuscation is just sign-extending a boolean to get either all zeros or all ones.

It makes a bit more sense in context, where [a, b][cond as usize] was @m-ou-se's sugestion.

[eddyb]

This version might look less obfuscated, and is probably a better fit for a test (originally it was just a Discord one-liner):

use std::mem::transmute;
fn main() {
    for &my_bool in &[true, false] {
        let mask = -(my_bool as i128); // false -> 0, true -> -1 aka !0
        unsafe {
            println!(
                "{}",
                transmute::<_, &str>(
                    !mask & transmute::<_, i128>("false !") | mask & transmute::<_, i128>("true !")
                )
            );
        }
    }
}

[RalfJung]

I see. However, given that the transmute already fails, I am not sure what the point of testing the rest is.^^

That said, I hope that Miri will support that kind of transmute one day (once #841 is done, which I am still occasionally working on). So maybe it's good to add the test now so we are reminded of it then.^^