-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
distinguish "no data" from "heterogeneous" in ABI #57645
distinguish "no data" from "heterogeneous" in ABI #57645
Conversation
PS, @glandium, you may want to try this build to see if it fixes your problem =) |
One interesting test where the right behavior is not obvious: #[repr(C)]
pub struct MiddleFieldPhantom {
pub a: f32,
pub b: f32,
pub c: [u32; 0],
pub d: PhantomData<u8>,
}
/// In the case where the VLA is in the middle, but the only thing
/// that comes next is phantomdata, we still consider that to be
/// `has_vla: false`. Not clear if that is correct but also not clear
/// that it is wrong.
#[rustc_layout(abi)]
pub type Test4 = MiddleFieldPhantom;
//~^ ERROR abi: Aggregate { sized: true, has_vla: false } |
74313f5
to
01e206d
Compare
This comment has been minimized.
This comment has been minimized.
01e206d
to
a1defb3
Compare
Tests just needed to be blessed. Hopefully ok now. |
913d548
to
6beebd0
Compare
@bors try |
⌛ Trying commit 6beebd0d109004f208b4241229ecedf12a752971 with merge 896270e14094a65293b52bbbf9b447c557dda848... |
@glandium when the try build above completes, we should produce an |
☔ The latest upstream changes (presumably #57321) made this pull request unmergeable. Please resolve the merge conflicts. |
☀️ Test successful - checks-travis |
I don't know what commit to give |
@glandium I think 896270e is correct; not sure why it didn't work, maybe @pietroalbini or @Mark-Simulacrum have a suggestion (they're the ones who advised me on how to do it) |
This command works for me:
|
So it looks like bors only built aarch64-unknown-linux-gnu host rustc? I can't test those, because we don't build Firefox on those. For aarch64-pc-windows-msvc, we build on x86_64-pc-windows-msvc. |
We can't do try builds for windows at the moment though. |
src/librustc/ty/layout.rs
Outdated
@@ -550,7 +572,7 @@ impl<'a, 'tcx> LayoutCx<'tcx, TyCtxt<'a, 'tcx, 'tcx>> { | |||
let abi = if count != 0 && ty.conservative_is_privately_uninhabited(tcx) { | |||
Abi::Uninhabited | |||
} else { | |||
Abi::Aggregate { sized: true } | |||
Abi::Aggregate { sized: true, has_vla: (count == 0) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a check for repr.c()
not warranted here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, never mind, its an array, which is repr(C)
by definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #56877 (comment) about VLA-ness of 0-sized arrays.
src/librustc/ty/layout.rs
Outdated
@@ -706,6 +738,13 @@ impl<'a, 'tcx> LayoutCx<'tcx, TyCtxt<'a, 'tcx, 'tcx>> { | |||
}; | |||
align = align.max(field_align); | |||
|
|||
// Track whether any field had the "VLA flag. | |||
if !any_variant_has_vla { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any particular reason other than a gut feeling for short-circuiting the code inside? To me it seems like a likely no-op performance wise.
src/librustc/ty/layout.rs
Outdated
if any_variant_has_vla && def.repr.c() { | ||
if let Abi::Aggregate { has_vla, .. } = &mut abi { | ||
*has_vla = true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly a style nit, this could be written as just
if let Abi::Aggregate { has_vla, .. } = &mut abi {
*has_vla |= any_variant_has_vla && def.repr.c();
}
src/librustc_target/abi/mod.rs
Outdated
/// a homogeneous aggregate. | ||
/// | ||
/// (Note that this field is always false for things that are | ||
/// not `#[repr(C)]`.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this field is always false for things that are not
#[repr(C)]
Seems like a difficult requirement to uphold in the future without something asserting this somewhere. I feel like the code downstream should be able to handle this field regardless of the overall ABI (i.e. interpret it semantically).
If an aggregate has a VLA within itself, it itself becomes variable-length, in which case it would make sense to just name this field as is_variable_length
...
Which then brings up a question: does it make sense for a variable-length aggregate to also be sized
? Well, at least the #[repr(C)] struct Foo { last: [T; 0] }
would be Aggregate { sized: true, variable_length: true }
, but then what really is it – a variable length aggregate or a zero-sized aggregate? Hmm...
To be fair, I’m not sure what ABI interactions arise here – the currently implemented behaviour may well be the correct one...
I feel like this could still use a codegen test for aarch regression, but sadly our codegen testing infrastructure does not currently allow testing assembly... |
I'm told this affects Fennec for aarch64 Android as well, and we build those on Linux. Can you do a try x86_64-pc-linux-gnu build (with aarch64 std)? |
I'll look at this when I'll have the time - don't know when will that be. |
I found this comment by @parched somewhat persuasive -- it basically argues that we don't really have a way to represent "VLA" in Rust today (it's almost a |
d0c4260
to
784a26d
Compare
Can you do a try x86_64-pc-linux-gnu build (with aarch64 std)? |
@nikomatsakis wrote:
can you update the PR description to reflect this change, so that the eventual bors commit will have a commit message that reflects reality? |
03dc540
to
99105b6
Compare
@eddyb I believe this now implements the change you wanted in the way that you wanted it =) if you approve, I'll squash the commits. |
030a15c
to
f622ed1
Compare
Squashed and rebased. r? @eddyb |
f622ed1
to
500a5ca
Compare
r=me with description updated |
Also, add a testing infrastructure and tests that lets us dump layout.
500a5ca
to
8e4c57f
Compare
@bors r=eddyb p=1 Giving high priority because this is blocking some folks at Mozilla |
📌 Commit 8e4c57f has been approved by |
…ates, r=eddyb distinguish "no data" from "heterogeneous" in ABI Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA. cc rust-lang#56877 r? @arielb1 cc @eddyb
Rollup of 5 pull requests Successful merges: - #56233 (Miri and miri-related code contains repetitions of `(n << amt) >> amt`) - #57645 (distinguish "no data" from "heterogeneous" in ABI) - #57734 (Fix evaluating trivial drop glue in constants) - #57886 (Add suggestion for moving type declaration before associated type bindings in generic arguments.) - #57890 (Fix wording in diagnostics page) Failed merges: r? @ghost
Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA.
cc #56877
r? @arielb1
cc @eddyb