Skip to content

#[repr(packed(N))] (tracking issue for RFC 1399) #33158

Description

@nikomatsakis

Tracking issue for rust-lang/rfcs#1399: #[repr(packed(N))]

Unresolved issues

  • Should borrows to packed fields be safe if the field's natural alignment is greater than or equal to the packing value, or should all fields of a packed struct always be unsafe to borrow?
  • 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?

Activity

  1. added
    B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.
    T-langRelevant to the language team
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    on Apr 22, 2016
  2. retep998 commented on May 26, 2016

    @retep998
    Contributor

    #27060 is closely related to this.

  3. added
    E-help-wantedCall for participation: Help is requested to fix this issue.
    on Feb 10, 2017
  4. bitshifter commented on Apr 23, 2017

    @bitshifter
    Contributor

    This should probably use attr_literals now like repr(align) does, e.g. repr(pack(2)).

  5. ahicks92 commented on Jun 26, 2017

    @ahicks92
    Contributor

    Is 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.

  6. ahicks92 commented on Jun 27, 2017

    @ahicks92
    Contributor

    Unless 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.

  7. eddyb commented on Jun 27, 2017

    @eddyb
    Contributor

    @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.

  8. ahicks92 commented on Jun 28, 2017

    @ahicks92
    Contributor

    @eddyb
    Should I wait on you?

  9. eddyb commented on Jun 28, 2017

    @eddyb
    Contributor

    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 align field.

  10. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Jul 22, 2017
  11. LegNeato commented on Oct 19, 2017

    @LegNeato
    Contributor

    @eddyb did you land the work-in-progress changes that were being discussed here?

  12. eddyb commented on Oct 19, 2017

    @eddyb
    Contributor

    @LegNeato They ended up in #45225, which might take a bit longer to get merged.

  13. fitzgen commented on Nov 1, 2017

    @fitzgen
    Member

    Is there anything I can do to help implement and stabilize this feature? We need it badly for bindgen.

  14. 64 remaining items

  15. rfcbot commented on Dec 20, 2018

    @rfcbot

    The final comment period, with a disposition to merge, as per the review above, is now complete.

  16. removed
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Dec 20, 2018
  17. Centril commented on Dec 20, 2018

    @Centril
    Contributor

    Any takers for a stabilization PR?

  18. cramertj commented on Dec 21, 2018

    @cramertj
    Member

    I'll do that.

  19. added a commit that references this issue on Dec 22, 2018
  20. Centril commented on Dec 23, 2018

    @Centril
    Contributor

    Reference documentation issue: rust-lang/reference#483.

  21. ic3man5 commented on Dec 12, 2023

    @ic3man5

    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).

  22. RalfJung commented on Dec 12, 2023

    @RalfJung
    Member

    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. ;)

  23. ic3man5 commented on Dec 12, 2023

    @ic3man5

    @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.

  24. RalfJung commented on Dec 12, 2023

    @RalfJung
    Member

    There are already issues for

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-help-wantedCall for participation: Help is requested to fix this issue.T-langRelevant to the language teamdisposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions