-
Notifications
You must be signed in to change notification settings - Fork 13.3k
fix for multiple #[repr(align(N))]
on functions
#139917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @nnethercote rustbot has assigned @nnethercote. Use |
Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs Some changes occurred in compiler/rustc_codegen_ssa |
I'll give this a review in a sec :) |
This looks good! Simple change, and also closes the issue. Nice :) @bors r+ rollup |
…onszelmann fix for multiple `#[repr(align(N))]` on functions tracking issue: rust-lang#82232 fixes rust-lang#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 rust-lang#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
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#139084 (hygiene: Rename semi-transparent to semi-opaque) - rust-lang#139236 (Use a session counter to make anon dep nodes unique) - rust-lang#139650 (Fix `register_group_alias` for tools) - rust-lang#139770 (Rename `LifetimeName` as `LifetimeKind`.) - rust-lang#139846 (Remove `kw::Empty` uses in rustdoc) - rust-lang#139891 (Include optional dso_local marker for functions in `enum-match.rs`) - rust-lang#139908 (parser: Remove old diagnostic notes for type ascription syntax) - rust-lang#139917 (fix for multiple `#[repr(align(N))]` on functions) Failed merges: - rust-lang#139615 (Remove `name_or_empty`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#139917 - folkertdev:fn-align-multiple, r=jdonszelmann fix for multiple `#[repr(align(N))]` on functions tracking issue: rust-lang#82232 fixes rust-lang#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 rust-lang#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
tracking issue: #82232
fixes #132464
The behavior of align is specified at https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.alignment.align
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:https://godbolt.org/z/scco435jE
rust/compiler/rustc_middle/src/ty/mod.rs
Lines 1529 to 1532 in afa859f
The #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 morealign
modifiers. In combination, that fixes the issue.cc @jdonszelmann if you do have further thoughs here