Skip to content

Tracking Issue for nested field access in offset_of #120140

Description

@GKFX

Feature gate: #![feature(offset_of_nested)]

This is a tracking issue for the use of nested field access in offset_of. This is currently implemented with dot-separated fields, like in C. The original RFC for offset_of was rust-lang/rfcs#3308.

Public API

pub macro offset_of($Container:ty, $($fields:expr)+ $(,)?) { ... }

struct Struct {
    field: A,
}
struct A {
    a: ((u8, u8), bool),
}
const OFFSET: usize = offset_of!(Struct, field.a.0.1);

Steps / History

Unresolved Questions

  • None yet.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libs-api[DEPRECATED; DO NOT USE]
    on Jan 19, 2024
  2. est31 commented on Jan 20, 2024

    @est31
    Member

    This has been split off from #106655 to get the non-nested offset_off macro stabilized sooner.

    How the syntax for nested access should look like is still subject to discussion, especially also how it relates to enums.

    Some links:

  3. tgross35 commented on May 22, 2024

    @tgross35
    Member

    Could the top example be updated to show what Struct looks like?

  4. GKFX commented on Jun 2, 2024

    @GKFX
    ContributorAuthor

    How close is this to stabilization? It looks like this is in use by the Linux kernel (https://lore.kernel.org/rust-for-linux/CAH5fLgjP98pS1wsP=YXP5Yr79Y62VF7XPKjbj+G75B3SOFt80g@mail.gmail.com/), as well as the standard library (for an enum):

    (self as *const Self).byte_add(core::mem::offset_of!(Self, Some.0)).cast(),

    Stabilizing this may restrict future changes to the offset_of parsing logic (compiler/rustc_parse/src/parser/expr.rs:1191, parse_floating_field_access). Currently this has enum variants treated the same as fields and (with parsing support only) array indexing using [expr] syntax.

  5. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    on Jun 9, 2024
  6. dingxiangfei2009 commented on Jun 11, 2024

    @dingxiangfei2009
    Contributor

    Cross-posting stabilization report and request because the two feature gates need to stabilize together for best utility.

    Report

    cc @Darksonn @ojeda

  7. Amanieu commented on Jun 17, 2024

    @Amanieu
    Member

    @rfcbot fcp merge

  8. rfcbot commented on Jun 17, 2024

    @rfcbot

    Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  9. added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Jun 17, 2024
  10. tmandry commented on Jun 20, 2024

    @tmandry
    Member

    I'm unclear on whether this needs an RFC. I would defer to libs-api on that question though, since this is more a question of the syntax the macro supports than the capability it provides, and I think the syntax is more in the libs-api realm than the lang one (though it may be a bit of both).

    Regarding the syntax, there is still an open question about supporting enum variants in the future. I'm personally okay with moving forward with this subset for now, especially since I can imagine a syntax I don't dislike: offset_of!(Struct, (field.a as MyEnum::Variant).0.1). But I'm just documenting my thinking here for future reference; we should leave the bikeshed out of this issue if at all possible.

    @rfcbot reviewed

  11. nikomatsakis commented on Jul 12, 2024

    @nikomatsakis
    Contributor

    @rfcbot reviewed

    I don't feel this requires an RFC. I think it is a natural extension to the existing functionality.

  12. added
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Jul 18, 2024
  13. rfcbot commented on Jul 18, 2024

    @rfcbot

    🔔 This is now entering its final comment period, as per the review above. 🔔

  14. removed
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    on Jul 18, 2024
  15. pnkfelix commented on Jul 19, 2024

    @pnkfelix
    Contributor

    @rfcbot reviewed

  16. added
    to-announceAnnounce this issue on triage meeting
    and removed
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Jul 28, 2024
  17. rfcbot commented on Jul 28, 2024

    @rfcbot

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

    As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

    This will be merged soon.

  18. added a commit that references this issue on Jul 29, 2024
  19. added a commit that references this issue on Jul 30, 2024
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-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-offset_of_nested`#![feature(offset_of_nested)]`T-langRelevant to the language teamT-libs-api[DEPRECATED; DO NOT USE]disposition-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