[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260129-try-from-into-macro-v5-0-dd011008118c@gmail.com>
Date: Thu, 29 Jan 2026 23:32:44 +0900
From: Jesung Yang via B4 Relay <devnull+y.j3ms.n.gmail.com@...nel.org>
To: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, Alexandre Courbot <acourbot@...dia.com>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
nouveau@...ts.freedesktop.org, Jesung Yang <y.j3ms.n@...il.com>
Subject: [PATCH v5 0/4] rust: add `TryFrom` and `Into` derive macros
This patch series introduces derive macros for the `TryFrom` and `Into`
traits.
I dropped support for `#[repr(C)]` fieldless enums (i.e., disallow
deriving `TryFrom` and `Into` on those enums), since the actual
representation of discriminants is defined by rustc internally, and
documentation around it is not yet settled [1][2].
I would like to highlight some feedback from the previous series where I
have decided to retain the original behavior in this series. In part, I
feel more community feedback is needed to reach the right design; I've
also elaborated on my personal reasoning for each point below:
1) Require explicit `#[repr(..)]` for enums using the macros.
Given the drop of `#[repr(C)]` support, I believe defaulting to `isize`
when no `#[repr(..)]` is specified is safe, as it follows the
compiler's (documented) default behavior [3]. By "safe", I mean I see no
potential regressions or hidden issues; we even have a compile-time
overflow assertion which ensure all enum discriminants fit within the
types involved in the conversion.
2) Generate trait implementation for a type in `#[repr(..)]` even when
the helper attribute is present. For example:
#[derive(TryFrom)]
#[try_from(bool)]
#[repr(u8)]
enum E {
A = 0,
B = 1,
}
make the above snippet generate both `TryFrom<u8>` and
`TryFrom<bool>` implementations.
However, sometimes users might want to prevent generating trait
implementations for the type in `#[repr(..)]`, especially when the enum
encodes types like `bool` or `Bounded<u8, 4>` that cannot be used in
`#[repr(..)]`, like the above snippet. If we were to follow the feedback
directly, users would end up with an unnecessary `TryFrom<u8>`
implementation. Therefore, I think it is reasonable to treat the helper
attribute as an override that ignores the type in `#[repr(..)]` when
present.
One last point: the current `Into` implementation relies on
`Bounded::from_expr()`, which utilizes `build_assert!()`. So the
expanded result looks roughly like this:
impl From<Enum> for Bounded<u8, 4> {
fn from(value: Enum) -> Bounded<u8, 4> {
// Compile-time assertions to guarantee `value` fits within
// `u8` (Omitted)
Bounded::<u8, 4>::from_expr(value as u8)
}
}
After some experimentation, it appears that the compiler correctly
optimizes out the assertion if (and only if) the `Bounded` type covers
all enum discriminants, though I'm not 100% certain of this behavior in
all cases. Can we approach this better?
Appreciate any feedback or suggestions.
[1] https://github.com/rust-lang/rust/issues/124403
[2] https://github.com/rust-lang/rust/pull/147017
[3] https://doc.rust-lang.org/reference/items/enumerations.html#r-items.enum.discriminant.repr-rust
Signed-off-by: Jesung Yang <y.j3ms.n@...il.com>
---
Changes in v5:
- Drop support for `#[repr(C)]` enums. (Benno Lossin)
- Allow `#[repr(C, {primitive_int_type})]` for future-proofing.
(Benno Lossin)
- Parse types in helper attributes into `syn::Type` prior to validation.
(Benno Lossin)
- Replace doctests for `TryFrom` with correct examples. (Benno Lossin)
- Reorganize error reporting structure.
- Add documentation about `#[repr(C)]` fieldless enums.
- Rebase on commit a7c013f77953 ("Merge patch series "refactor Rust proc
macros with `syn`"")
- Link to v4: https://lore.kernel.org/r/20251225-try-from-into-macro-v4-0-4a563d597836@gmail.com
Changes in v4:
- Fix typos.
- Link to (broken) v3: https://lore.kernel.org/rust-for-linux/cover.1766544407.git.y.j3ms.n@gmail.com/
Changes in v3:
- Use the vendored `syn` and `quote` crates.
- Support `kernel::num::Bounded`.
- Add compile-time overflow assertion.
- Add a comment about `#[repr(C)]` enums.
- Drop Tested-by and Reviewed-by tags, as the code structure has
changed substantially. (Thanks for the previous reviews and testing!)
- Link to v2: https://lore.kernel.org/rust-for-linux/cover.1755235180.git.y.j3ms.n@gmail.com/
Changes in v2 (no functional changes):
- Split the patch "rust: macros: extend custom `quote!()` macro"
into two separate patches.
- Remove unnecessary spaces between tags.
- Use a consistent commit subject prefix: "rust: macros:".
- Add Tested-by tags.
- Link to v1: https://lore.kernel.org/rust-for-linux/cover.1754228164.git.y.j3ms.n@gmail.com/
---
Jesung Yang (4):
rust: macros: add derive macro for `Into`
rust: macros: add derive macro for `TryFrom`
rust: macros: add private doctests for `Into` derive macro
rust: macros: add private doctests for `TryFrom` derive macro
rust/macros/convert.rs | 1599 ++++++++++++++++++++++++++++++++++++++++++++++++
rust/macros/lib.rs | 349 ++++++++++-
2 files changed, 1947 insertions(+), 1 deletion(-)
---
base-commit: a7c013f779530190d0c1e1aa5e7c8a61f0bd479e
change-id: 20251225-try-from-into-macro-1665d0afcfc8
Best regards,
--
Jesung Yang <y.j3ms.n@...il.com>
Powered by blists - more mailing lists