&A as *const _ == &A as *const _ not guaranteed for `const A`

[oli-obk]

miri creates two allocations for the *b"hi" in A.
see MIR in https://is.gd/bCUD7p
This makes sense, since there's _1 = A; _2 = &_1 instead of _2 = &A.

Should this

a) be fixed in rustc, or
b) should we cache all literals (we have FIXMEs for that), or
c) should we add some Cow-like structure to lvalues, so they can refer to other lvalues "ByVal"?
d) is the test ( https://github.com/rust-lang/rust/blob/master/src/test/run-pass/const-str-ptr.rs ) wrong?

@eddyb: any preferences?

Found more evidence for b and against d:

#![feature(const_fn)]

const fn foo() -> *const i8 {
    b"foo" as *const _ as *const i8
}

const fn bar() -> i32 {
    *&{(1, 2, 3).1}
}

fn main() {
    assert_eq!(foo(), b"foo" as *const _ as *const i8);
    assert_eq!(bar(), 2);
}

[solson]

@nikomatsakis and @eddyb were just talking about a way to change how promoteds work that I think might fix this problem. (I.e. I'm leaning a. However, I think we have other reasons to do b anyway.)

[eddyb]

Specifically, changing promoted fragments to be lvalues instead of constant rvalues and moving the reference out, so they're (inside a function) runtime borrows of static lvalues instead of copies of constant rvalues, and then we also want borrows inside const and static to also be explicitly promoted.

@nikomatsakis likes this and I agree it should work better, at least in the sense that you're encoding the "right" semantics, as you likely want to allow &0 and ban { let x = 0; &x } in constants.
We can fully define it in terms of rvalue "drop scopes" but those are not computed for constants atm AFAIK.

[solson]

I implemented b in 6ffd700 but we'll still need the fix for promoteds.

[oli-obk]

Another example from the rustc test suite:

use std::{str, string};

const A: [u8; 2] = ['h' as u8, 'i' as u8];
const B: &'static [u8; 2] = &A;
const C: *const u8 = B as *const u8;

pub fn main() {
    unsafe {
        let foo = &A as *const u8;
        assert_eq!(foo, C);
        assert_eq!(str::from_utf8_unchecked(&A), "hi");
        assert_eq!(*C, A[0]);
        assert_eq!(*(&B[0] as *const u8), A[0]);
    }
}

[RalfJung]

This test also differs between rust (it passes) and miri (it fails):

fn main() {
    assert!(&A as *const A as *const () == &() as *const _);
    assert!(&A as *const A == &A as *const A);
}

[RalfJung]

This seems to be just an instance of "we should not really allocate ZSTs", right? I.e., fixing this should also fix the above test.

[oli-obk]

We'll still have some zsts whose address would differ, e.g. because they are in a field of another type. I don't feel too strongly about any variant, but I'm not sure what semantics we want in const eval

[RalfJung]

Actually this has nothing to do with ZST allocation. rustc somehow makes it so that with

promoted0 in main: &() = {
    let mut _0: &();                     // return pointer
    let mut _1: ();

    bb0: {
        _1 = ();                         // scope 0 at src/main.rs:10:45: 10:47
        _0 = &_1;                        // scope 0 at src/main.rs:10:44: 10:47
        return;                          // scope 0 at src/main.rs:10:44: 10:47
    }
}

promoted1 in main: &A = {
    let mut _0: &A;                      // return pointer
    let mut _1: A;

    bb0: {
        _1 = A::{{constructor}};         // scope 0 at src/main.rs:10:14: 10:15
        _0 = &_1;                        // scope 0 at src/main.rs:10:13: 10:15
        return;                          // scope 0 at src/main.rs:10:13: 10:15
    }
}

the code

        _8 = promoted1;                  // scope 0 at src/main.rs:10:13: 10:15
        _7 = _8;                         // scope 0 at src/main.rs:10:13: 10:15
        _6 = _7 as *const A (Misc);      // scope 0 at src/main.rs:10:13: 10:15
        _5 = _6;                         // scope 0 at src/main.rs:10:13: 10:27
        _4 = _5 as *const () (Misc);     // scope 0 at src/main.rs:10:13: 10:40
        _12 = promoted0;                 // scope 0 at src/main.rs:10:44: 10:47
        _11 = _12;                       // scope 0 at src/main.rs:10:44: 10:47
        _10 = _11 as *const () (Misc);   // scope 0 at src/main.rs:10:44: 10:47
        _9 = _10;                        // scope 0 at src/main.rs:10:44: 10:59
        _3 = Ne(_4, _9);                 // scope 0 at src/main.rs:10:13: 10:59
        _2 = Not(_3);                    // scope 0 at <assert macros>:2:4: 2:12

ends up saying that the two pointers are equal. Is it going deduplication of promoted constants or how is that working?

[eddyb]

All immutable constants are deduplicated in librustc_trans - basically, interned.

[RalfJung]

TBH I do not feel "bug" is the right label for this; we don't guarantee this deduplication (I would think) so what miri does seems reasonable to me. For example, does it happen across crates?

We could also make it error out when comparing, because we don't want to predict run-time behavior. Not sure if that would be better.

[oli-obk]

So... I've come to the conclusion that we can only compare

• statics with interior mutability or static mut
• live heap allocations
• live mutable locals

without erroring, because any other comparisons might differ between execution and interpretation.

Of course pointers into the same allocation can always be compared.

[eddyb]

Even immutable statics are still guaranteed distinct address, though?