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

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?

I agree; direct .0, .1 is nicer and more reasonable. Will fix

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)

I see.. I'll make tuple fields use the same methods

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 · 2026-07-11T15:06:17Z

I pushed new changes that addressed your comments and rebased.

nbdd0121 · 2026-07-20T15:04:01Z

Can you rebase on #161?

nbdd0121 · 2026-07-27T13:36:38Z

    else {
        unreachable!()
    };
+    let unpin_allow = if fields.iter().any(|f| matches!(f.member, Member::Named(_))) {


I'd rather unconditionally allow non_snake_case. Same elsewhere.

nbdd0121 · 2026-07-27T13:36:58Z

-    // type. If a field is structurally pinned, we create a `Slot` with `Pinned` which must be
-    // initialized via `PinInit`; if it is not structurally pinned, then we create a `Slot` with
-    // `Unpinned` which allows initialization via `Init`.
+    // For every field, we create an initializing projection function according to its


Why is the comment changed?

nbdd0121 · 2026-07-27T13:38:16Z

+            let field_safety_docs = match member {
+                Member::Named(_) => quote! {
+                    /// - `(*slot).#field_name` is properly aligned.
+                    /// - `(*slot).#field_name` points to uninitialized and exclusively accessed
+                    ///   memory.
+                },
+                Member::Unnamed(_) => quote! {
+                    /// - The field is properly aligned.
+                    /// - The field points to uninitialized and exclusively accessed memory.
+                },
+            };


nbdd0121 · 2026-07-27T13:38:48Z

+    let pin_data_new = quote! {
+        __ThePinData { __phantom: ::pin_init::__internal::PhantomInvariant::new() }
+    };


nbdd0121 · 2026-07-27T13:39:50Z

+
+fn member_binding(member: &Member) -> Option<Ident> {
+    match member {
+        Member::Named(ident) => Some(ident.clone()),


No need to clone here.

nbdd0121 · 2026-07-27T13:40:21Z

-                // - `make_field_check` checks that `&raw mut (*slot).#ident` is properly aligned.
-                // - `make_field_check` prevents `#ident` from being used twice, therefore
-                //   `(*slot).#ident` is exclusively accessed and has not been initialized.
+                // - `make_field_check` checks that the field is properly aligned.


Why updating the comment here?

nbdd0121 · 2026-07-27T14:00:55Z

    path: Path,
    delim_close_span: Span,
    fields: Punctuated<InitializerField, Token![,]>,
+    is_tuple_constructor: bool,


If the code wouldn't be over-complicated, I would change this the parsing to give two distinct types for tuple syntax and struct syntax.

pub(crate) struct InitStruct { path: Path, brace: token::Brace, fields: Punctuated<InitializerField, Token![,]>, rest: Option<(Token![..], Expr)>, } pub(crate) struct InitTuple { path: Path, paren: token::Paren, fields: Punctuated<Expr, Token![,]>, } impl InitTuple { fn to_init_struct(self) -> InitStruct { ... } } pub(crate) enum InitKind { .. } pub(crate) struct Initializer { ... }

nbdd0121 · 2026-07-27T14:33:06Z

+        if let Some(attr) = field.attrs.iter().find(|attr| attr.path().is_ident("cfg")) {
+            return Err(dcx.error(
+                attr,
+                "`#[cfg]` on tuple constructor arguments is only supported on the last argument",


Suggested change

"`#[cfg]` on tuple constructor arguments is only supported on the last argument",

"`#[cfg]` is not supported in this position",

this whole commit should be folded into commit 2.

nbdd0121 · 2026-08-03T16:19:44Z

Could you handle cfgs in a way similar to #165? Unlike #[pin_data], I am inclining not to always expand out cfg in init!() as there is no other need for this, unlike #[pin_data] where self-ref pin init also needs expanded cfgs, so #165 is probably not going to be merged, but the approach can work for tuple structs.

mqqz · 2026-08-04T09:08:03Z

I'll rethink this PR as a whole and double check (the last few fixes were rushed because they were slaving me away at work)

nbdd0121 · 2026-08-04T10:14:39Z

Thanks for working on this!

mqqz · 2026-08-28T15:02:50Z

oh its my absolute pleasure to work on this. I took my time to fix botched rebase and clean up commits. Also, I think CI is broken now.

Binding a value of an uninhabited type now makes everything following it unreachable. In `stack_pin_init!` the `Infallible` annotation is such a binding, so the `match x {}` after it is reported as unreachable and `-Dwarnings` turns that into an error. Annotate the `Result` instead of the error value, which requires the initializer to be infallible just the same but has nothing following it. `Infallible` is also printed as `!` in diagnostics now, so bless the two tests that show it. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

`#[pin_data]` rejects tuple structs because it assumes every field has a name, which it uses for the projection field, the `__Unpin` field and the pin-data accessor. Identify fields by `syn::Member` instead, so that tuple fields are referred to by their index in generated field accesses. The names that generated items still need are derived from the index as `_0`, `_1`, ...; put that mapping in one place, since `[pin_]init!` has to call the accessors it names. The projection of a tuple struct is a tuple struct itself, so projected fields are accessed with the same `.0`, `.1`, ... syntax as on the input type rather than through synthesised names. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

Extend the initializer syntax so that a field can be named by an index, addressing tuple struct fields the same way a struct expression does: pin_init!(Foo { 0: value, 1 <- initializer }) Tuple fields are not exposed by a `let` binding to the fields after them, since they have no name to bind; `_0` would shadow a user variable. `cfg` needs different treatment from named fields. Non-derive proc macros are invoked before cfg is resolved, so the macro cannot know whether a field survives, and dropping a tuple field renumbers every field after it. That cannot be expressed by attaching a `cfg` attribute to the initializer of a single field. Resolve tuple field cfgs up front instead, by generating two cfg-gated invocations of the macro with one field resolved in each. This is the approach of commit 3445a65 ("internal: rework how `#[pin_data]` handles cfg"), and it is linear because only one of the two branches is ever expanded. Named fields do not renumber, so they keep using the existing attribute-based handling. Link: Rust-for-Linux#165 Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

A tuple struct whose fields are all set to a value reads better written like a call to its constructor than with the indices spelled out: pin_init!(Foo(value, value)) Parse the two forms into separate types and rewrite the constructor arguments into the indexed fields they are shorthand for, so that only the parser has to know about the second form. The arguments have no names, so they cannot use `<-`. Parse it anyway and reject it afterwards, which reports the position of every offending `<-` rather than stopping at the first one. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>

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

mqqz force-pushed the add_tuple_structs_v2 branch 4 times, most recently from 5a4e625 to 65d2dc5 Compare July 11, 2026 15:05

mqqz requested a review from nbdd0121 July 11, 2026 15:24

nbdd0121 mentioned this pull request Jul 13, 2026

internal: rework how #[pin_data] handles cfg #161

Merged

mqqz force-pushed the add_tuple_structs_v2 branch 2 times, most recently from 9a5c70e to a61d14e Compare July 25, 2026 00:08

mqqz changed the base branch from main to dev/cfg July 25, 2026 00:15

nbdd0121 changed the base branch from dev/cfg to main July 27, 2026 10:53

nbdd0121 reviewed Jul 27, 2026

View reviewed changes

nbdd0121 mentioned this pull request Jul 30, 2026

rework how [pin_]init! handles cfg #165

Open

mqqz force-pushed the add_tuple_structs_v2 branch from a61d14e to ec74456 Compare August 28, 2026 11:42

mqqz added 4 commits August 28, 2026 18:14

mqqz force-pushed the add_tuple_structs_v2 branch from ec74456 to 3ec0b2f Compare August 28, 2026 15:19

mqqz mentioned this pull request Aug 28, 2026

fix build with latest nightly #171

Open

	"`#[cfg]` on tuple constructor arguments is only supported on the last argument",
	"`#[cfg]` is not supported in this position",

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!

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!

Choose a reason for hiding this comment

Uh oh!

mqqz commented Jul 11, 2026

Uh oh!

nbdd0121 commented Jul 20, 2026

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!

nbdd0121 commented Aug 3, 2026

Uh oh!

mqqz commented Aug 4, 2026

Uh oh!

nbdd0121 commented Aug 4, 2026

Uh oh!

mqqz commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

mqqz commented May 22, 2026 •

edited

Loading