implement `#[repr(align)]` (tracking issue for RFC 1358)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1358

[kennytm]

heap::EMPTY is currently defined as 1 and is used as the address of reference to zero-sized types. Would it affect the program's correctness if we change the alignment of a ZST?

#[repr(align="8")]
struct F;

println!("{:p}", Box::new(F));
// prints 0x1? 0x8?

cc #27700.

[retep998]

@kennytm That already is an issue without this RFC.

use std::mem::align_of;
struct F([u32; 0]);
println!("{:p}", Box::new(F)); //prints 0x1
println!("{}", align_of::<F>()); //prints 4

[kennytm]

@retep998 Okay thanks. So it is entirely an issue of #27700.

[whitequark]

Anyone else implementing this? I need it so I may give it a go.

[mfarrugi]

What's the relationship of this issue to simd support #27731 (ie. the current way to accomplish this on nightly)?

Can/should this be implemented separately?

[lu-zero]

@mfarrugi the two are related but not that much. SIMD usually works better on aligned data, but you need aligned data also when you use other kind of hardware features (dma engines for crypto, video decoding/encoding, etc). @whitequark got time to implement it? From what I can see the allocator now is taking an alignment so it should be not terrible to implement (I do not know the rust internals well enough to be confident in poking around this).

[whitequark]

@lu-zero Ok let me give it another try. Rustbuild and (hopefully?) incremental compilation have made rustc hacking much less painful...

[bitshifter]

@whitequark have started on this? I was interested and got a proof of concept working, so if you haven't started on it I could probably finish off what I'm doing and make a PR. I'd probably need some mentoring from someone, I haven't added a feature before.

[whitequark]

@bitshifter not really, please go ahead!