Multiple alignments on functions (`#![feature(fn_align)]`)

[jdonszelmann]

This code specifies two alignments, but applies none. A single align(256) does work

#![feature(fn_align)]


#[repr(align(256), align(256))]
pub fn main() {
    let ptr = main as *const u8;
    println!("{ptr:?}");

    assert_eq!(ptr.align_offset(256), 0);
}

See here: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=f841ae6318f0f7abdab285ea9ec641ab

CC: #82232

The culprit is this line here matching on slices of length 1:

rust/compiler/rustc_codegen_ssa/src/codegen_attrs.rs

Lines 418 to 420 in 145f9cf

	codegen_fn_attrs.alignment = if let Some(items) = attr.meta_item_list()
	&& let [item] = items.as_slice()
	&& let Some((sym::align, literal)) = item.singleton_lit_list()

It's a one line fix, but honestly this is trivially resolved with rust-lang/compiler-team#796 which I'm working on. I'll make it a separate PR at some point, but I'll assign myself since it makes sure changes conflict a little less :)

@rustbot claim

[jdonszelmann]

@rustbot label +A-repr +A-align

[folkertdev]

This problem has been partially solved, but there is still a logic error when more than one alignment is specified.

Currently, the logic picks the first alignment that is given. That is inconsistent with alignment on data structures which picks the highest specified alignment.

#![feature(fn_align)]

#[repr(C,  align(32), align(64))]
struct Foo {
    x: u64,
}

const _: () = assert!(core::mem::align_of::<Foo>() == 64);

// See the godbolt LLVM output: the alignment of this function is 32
#[no_mangle]
#[repr(align(32))]
#[repr(align(64))]
fn foo() {}

// The current logic just picks the first alignment: the alignment of this function is 64
#[no_mangle]
#[repr(align(64))]
#[repr(align(32))]
fn bar() {}!("{}", core::mem::size_of::<Foo>());
}

https://godbolt.org/z/scco435jE

The behavior of align is specified at https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.alignment.align

For align, if the specified alignment is less than the alignment of the type without the align modifier, then the alignment is unaffected.

So in effect that means that the maximum value should be chosen.

@jdonszelmann is it OK if I open a PR fixing this final problem (given that you've claimed the issue)? Maybe something attribute-related is not done yet?