Rollup merge of #139917 - folkertdev:fn-align-multiple, r=jdonszelmann

fix for multiple `#[repr(align(N))]` on functions

tracking issue: https://github.com/rust-lang/rust/issues/82232
fixes https://github.com/rust-lang/rust/issues/132464

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 of the specified alignments should be chosen. That is also the current behavior for `align` on ADTs:

```rust
#![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() {}
```

https://godbolt.org/z/scco435jE

https://github.com/rust-lang/rust/blob/afa859f8121bf2985362a2c8414dc71a825ccf2d/compiler/rustc_middle/src/ty/mod.rs#L1529-L1532

The https://github.com/rust-lang/rust/issues/132464 issue is really about parsing/representing the attribute, which has already been improved and now uses the "parse, don't validate" attribute approach. That means the behavior is already different from what the issue describes: on current `main`, the first value is chosen. This PR fixes a logic error, where we just did not check for the effect of two or more `align` modifiers. In combination, that fixes the issue.

cc ``@jdonszelmann`` if you do have further thoughs here

0 files changed, 0 insertions, 0 deletions