lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ