-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
aarch64 ABI: revisit which ZST fields should be filtered from repr(C) #58487
Copy link
Copy link
Open
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-FFIArea: Foreign function interface (FFI)Area: Foreign function interface (FFI)A-reprArea: the `#[repr(stuff)]` attributeArea: the `#[repr(stuff)]` attributeT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-FFIArea: Foreign function interface (FFI)Area: Foreign function interface (FFI)A-reprArea: the `#[repr(stuff)]` attributeArea: the `#[repr(stuff)]` attributeT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Spawned off of #56877 (comment) and #57645 (comment)
The issues raised by #56877 were partially addressed by PR #57645 but there may be some followup work to do here.
Based on my current understanding, PR #57645 ended up settling on filtering out all ZST's when determining if a type is an instance of a so-called "homogeneous aggregate", and the remaining question is whether we have to deal with architecture/target dependencies when resolving the semantic question of whether the Rust type
[T; 0]should map to the C typeT[0]or toT[].Namely, it sounds like AArch64 may require us to restrict the filtering we do (for determining whether a type is a homogenous aggregate) to just the Rust ZST's like
PhantomData.Anyway, this issue is to tracking that leftover work to resolve that question.