Tracking Issue for nested field access in offset_of

[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

• Implementation: Included in initial offset_of implementation
• Final comment period (FCP)¹
• Stabilization PR - Stabilize offset_of_nested #128284

Unresolved Questions

• None yet.

Footnotes

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

[est31]

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:

• zulip thread about offset_of syntax
• tracking issue for enums in offset_of. Contains some of the syntax discussion.
• The PR that added enum support to offset_of also contains some syntax discussion.

[tgross35]

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

[GKFX]

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

rust/library/core/src/option.rs

Line 787 in 13e2d72

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

[dingxiangfei2009]

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

Report

cc @Darksonn @ojeda

[Amanieu]

@rfcbot fcp merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

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.

[tmandry]

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

[nikomatsakis]

@rfcbot reviewed

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

[rfcbot]

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

[pnkfelix]

@rfcbot reviewed

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