Repository navigation
#[repr(packed(N))] (tracking issue for RFC 1399) #33158
Description
Activity
- addedB-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.T-langRelevant to the language teamRelevant to the language teamB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.
on Apr 22, 2016 #27060 is closely related to this.
- addedE-help-wantedCall for participation: Help is requested to fix this issue.Call for participation: Help is requested to fix this issue.
on Feb 10, 2017 This should probably use
attr_literalsnow likerepr(align)does, e.g.repr(pack(2)).Reacted by Niko MatsakisIs anyone working on this? If not I think I mostly know how to do it, modulo someone telling me how the attribute parsing and verification needs to be extended higher up.
Reacted by Peter Atashian and Ivan UkhovUnless someone comes in and says they're doing this before then, I'm going to take a crack at it Friday or thereabouts. My intent is to use the attribute literals approach (or support both if that's what people want), plus potentially submitting a PR against the RFC repo to update the RFC to attribute literals.
@eddyb or whoever else might know: is inserting a bunch of
[0 x u8]in packed structs going to degrade performance? The easiest approach here seems to be to multiply everything in the type index to memory index vector by 2, then insert such dummy fields in packed structs. I think that everything else after that may just work except maybe constructing constants for them, but iirc constant construction is in one place and relatively easy for me to fix in this way.@camlorn everything currently has those usually-empty arrays, for
#[repr(align(N))].
I also have a work-in-progress branch where I've simplified a lot of trans (including making constant ADTs boring), but there's more to be done - maybe I should try to polish it and open a PR soon.@eddyb
Should I wait on you?I'd say so, yes, at least for the trans part. In fact, I'm not sure there is anything left to do once I'm done, other than use the value from the attribute in the
alignfield.- addedC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC
on Jul 22, 2017 @eddyb did you land the work-in-progress changes that were being discussed here?
Is there anything I can do to help implement and stabilize this feature? We need it badly for
bindgen.Reacted by Ivan Ukhov, Peter Atashian, Tim Ryan and Vsevolod Zubarev64 remaining items
- addedfinished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
on Dec 20, 2018 The final comment period, with a disposition to merge, as per the review above, is now complete.
- removedfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
on Dec 20, 2018 Any takers for a stabilization PR?
I'll do that.
Reacted by MSxDOSReference documentation issue: rust-lang/reference#483.
Noting action item
Currently #[repr(packed())] structs cannot transitively contain #[repr(align())] structs due to differing behavior between msvc and gcc. Do we want to keep this a hard error, pick one behavior over the other, or provide some way to choose which behavior is desired?
seems to have been missed in review (unless I missed it reading through all the comments).
That case still errors currently. So the resolution "keep this a hard error" was picked, maybe implicitly. This should be forward-compatible with the other options.
If you have further questions, I suggest asking on Zulip. Issue necromancy doesn't usually end well. ;)
Reacted by David@RalfJung Would opening a new issue be the correct solution then? If we want to have complete interoperability with C, this is a needed feature since C can align and pack at the same time. The linked issue does show a need for this feature.
There are already issues for
- having packed & align on the same type: E0587 error on packed and aligned structures from C #59154
- having packed structs with aligned fields: #[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs #100743
Reacted by David
Tracking issue for rust-lang/rfcs#1399:
#[repr(packed(N))]Unresolved issues
#[repr(packed(_))]structs cannot transitively contain#[repr(align(_))]structs due to differing behavior between msvc and gcc. Do we want to keep this a hard error, pick one behavior over the other, or provide some way to choose which behavior is desired?