@oli this https://github.com/rust-lang/rust/pull/67000 is now ready
it sits on top of https://github.com/rust-lang/rust/pull/67192
which you were discussing with @RalfJ
I need to check that PR again but at some point saw that @RalfJ was asking for some motivation about the PR, well if it helps a bit #67000 is part of the motivation :smile:
So the problem with #67000 is that since we now make all promoteds essentially
let tmp = promoted; &tmp, the addr-of-zst-promoted-becomes-integer-pointer logic in codegen isn't triggered anymore, thus causing test failures where we compare the address
1. While we could fix this just in codegen, this would severely complicate codegen, and also cause the weird situation where
assert!(&() as *const () as usize == 1) fails at compile-time but works at runtime
I am questioning those tests, Is there an RFC/FCP that we guarantee the address of temporary 1-ZSTs to be 1?
should we just brick them all?
I'm trying to remember. I certainly don't recall guaranteeing the address of a ZST to be anything other than "not null"
we don't afaict, but we have done some work to make the addresses whatever
std::ptr::dangling returns: https://github.com/rust-lang/rust/pull/62487
Yeah, I had a vague memory of that
We should I guess clarify exactly what we are specifying; there may be de facto reliance on
( cc @scottmcm )
but I didn't interpret that PR as any form of "guarantee" for sure
I didnt' quite understand where the various perf/compiler wins came from there, I guess maybe it had more to do with however we were compiling things before..?
the perf wins came from llvm not creating allocations
I don't think any code can be relying on it, because
let x: [i32; 0] = ; let y = &[x] will not give
y a dangling address