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@gmail.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@gmail.com>

On 29/01/26 20:02, Jesung Yang wrote:
> 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@gmail.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,
Tested-by: Shivam Kalra <shivamklr@cock.li>
Tested on rust-next with:
- make LLVM=1 rusttest (all doctests pass)
- make LLVM=1 CLIPPY=1 rust/ (compiles without warnings)
- make LLVM=1 -j$(nproc) (full kernel build succeeds)