internal: add tuple struct support in `pin_data` and `pin_init!` (V2) by mqqz · Pull Request #155 · Rust-for-Linux/pin-init

mqqz · 2026-05-22T19:01:07Z

Replaces #113.

This adds tuple struct support to #[pin_data], init!, and pin_init!.

The projected form of a tuple struct is also a tuple struct, so projected fields are accessed with native tuple syntax (.0, .1, ...), which keeps the generated API closer to
ordinary Rust and avoids exposing synthetic field names (also makes it easier fields are cfg'd out).

tuple struct projections from #[pin_data]
tuple struct initialization with indexed brace syntax:
- pin_init!(Foo { 0 <- ..., 1: ... })
tuple struct initialization with constructor syntax:
- pin_init!(Foo(...)) (but no <- e.g. Foo(a, <- b, c) is rejected)
support for tuple structs with generics, const generics, pinned drop, and fallible partial initialization rollback
~~support for tuple structs when fields or constructor arguments are removed by #[cfg]~~ (Error out unless #[cfg] is on the final tuple field)

Notes

tuple projections use native tuple field access rather than synthetic names e.g. ._0 like last time.
~~cfg handling does not try to evaluate user #[cfg] conditions in the proc macro~~
~~instead, the macro generates the necessary cfg-dependent layouts and lets rustc select the active branch~~
#[cfg] is supported only on the final tuple field / constructor argument, when it does not change numbering.

Tests

Added coverage for:

basic tuple struct projection
brace and constructor tuple initialization syntax
duplicate / missing / invalid tuple field UI failures
generic and const-generic tuple structs
#[pin] interaction with !Unpin field types
pinned drop
fallible partial-init rollback
cfg-stripped tuple fields (last or otherwise)
cfg-stripped tuple constructor arguments
~~feature-dependent cfg field layouts~~

Comparison with the old PR

This replaces the earlier attempt in #113.

Compared with that PR, this version is intentionally narrower and easier to review:

less code motion/churn overall (my code always got motion 😎)
fewer refactors mixed into the feature work
tuple projections are tuple structs instead of relying on synthetic internal/public field names
cfg handling was ~~redesigned to correctly handle cfg-stripped tuple fields and constructor arguments~~ simplified to accept only on last field/arg. or error out
the test set was trimmed to the non-redundant cases, while keeping the important regressions and restoring the fallible partial-init rollback coverage

Closes: #85

Add plumbing for tuple struct support to `#[pin_data]` by generating tuple struct projections and tuple-aware pin-data metadata. Keep the projection API native to Rust tuple structs, so projected fields are accessed as `.0`, `.1`, etc. instead of introducing synthetic public field names. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

Expand `init!` and `pin_init!` to initialize tuple structs using both indexed brace syntax and tuple-constructor syntax. Add tuple-specific runtime and UI coverage for the basic initializer forms, duplicate/missing fields, invalid indices, and syntax errors. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

Extend tuple-struct coverage with the semantic cases that are easiest to review independently from the implementation changes. Add runtime coverage for generic and const-generic tuple structs, `Unpin` behaviour with `!Unpin` field types, pinned drop, and fallible partial-init rollback. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

Support tuple structs whose final field or final constructor argument is removed by #[cfg]. This preserves tuple indices without needing to evaluate user cfgs in the proc macro. Reject #[cfg] on earlier tuple fields and tuple constructor arguments, because those cases would require reindexing the remaining fields after cfg stripping. That is possible to generate, but the extra complexity is not justified for the tuple struct support added here. Add regression tests for the supported final-field case and UI diagnostics for the unsupported index-shifting cases. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

nbdd0121 · 2026-06-05T10:48:19Z

+            return Err(syn::Error::new_spanned(
+                attr,
+                "`#[cfg]` on tuple constructor arguments is only supported on the last argument",
+            ));


This should be checked after parsing, thus would allow it to use the dcx mechanism and provide better error recovery.

nbdd0121 · 2026-07-01T10:54:43Z

+fn member_ident(member: &Member) -> Ident {
+    match member {
+        Member::Named(ident) => ident.clone(),
+        Member::Unnamed(Index { index, .. }) => format_ident!("_{index}"),
+    }
+}
+
+fn member_display_name(member: &Member) -> String {
+    match member {
+        Member::Named(ident) => format!("`{ident}`"),
+        Member::Unnamed(Index { index, .. }) => format!("index `{index}`"),
+    }
+}
+


These should be methods of FieldInfo

nbdd0121 · 2026-07-01T11:11:51Z

+                ));
+                field_projections.push(quote!(#binding,));
+            }
+            field_bindings.push(quote!(ref mut #binding,));


Any reason to use this instead of .0, .1, etc?

nbdd0121 · 2026-07-01T11:13:32Z

+                    #ty,
+                >,
+            });
+            field_values.push(quote! {


This is changing how tuple struct is handled to be completely different from normal structs?

There's a reason that methods are used, because they support HRTB, so it makes it possible to add self-reference support later (#156)

nbdd0121 · 2026-07-01T11:21:39Z

    this: Option<This>,
    path: Path,
-    brace_token: token::Brace,
+    close_span: Span,


Suggested change

close_span: Span,

delim_close_span: Span,

nbdd0121 · 2026-07-01T11:23:38Z

+        if input.peek(Token![<-]) {
+            return Err(input.error(
+                "`<-` is not supported in tuple constructor syntax; use braces with indices, e.g. `Type { 0 <- init, 1: value }`",
+            ));


I'd move this into parse_paren_initializer and drop the type.

nbdd0121 · 2026-07-01T11:25:09Z

            field_bindings.push(quote!(ref mut #binding,));
        }
+        let projection_init = if let Some(last_field) = fields.last() {
+            if let Some(cfg) = cfg_condition(&last_field.field.attrs) {


You should just unconditionally apply cfgs?

nbdd0121 · 2026-07-01T11:26:15Z

+    let tuple_fields: Vec<_> = tuple_fields.into_iter().collect();
    let mut fields = Punctuated::new();
+
+    for tuple_field in tuple_fields


Cfg rejection should happen before tuple struct is accepted at all, so there is no intermediate commit that allows it but performs incorrectly.

mqqz force-pushed the add_tuple_structs_v2 branch from c9dab99 to 1f2c279 Compare May 22, 2026 19:06

mqqz mentioned this pull request May 22, 2026

internal: add tuple struct support in pin_data and pin_init! #113

Closed

nbdd0121 reviewed May 25, 2026

View reviewed changes

Comment thread internal/src/init.rs Outdated

mqqz added 4 commits May 25, 2026 19:26

mqqz force-pushed the add_tuple_structs_v2 branch from 1f2c279 to 2d2042e Compare May 25, 2026 16:32

nbdd0121 requested changes Jul 1, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

internal: add tuple struct support in `pin_data` and `pin_init!` (V2)#155

internal: add tuple struct support in `pin_data` and `pin_init!` (V2)#155
mqqz wants to merge 4 commits into
Rust-for-Linux:mainfrom
mqqz:add_tuple_structs_v2

mqqz commented May 22, 2026 •

edited

Loading

Uh oh!

Uh oh!

nbdd0121 Jun 5, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

nbdd0121 Jul 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mqqz commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Notes

Tests

Comparison with the old PR

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

mqqz commented May 22, 2026 •

edited

Loading