Skip to content

fix(macros): ignore #[repr(C)] and other non-integer reprs in derive(Type) for enums - #4508

Open
thelastbackspace wants to merge 1 commit into
transact-rs:mainfrom
thelastbackspace:fix/4366-repr-c-enum
Open

thelastbackspace wants to merge 1 commit into
transact-rs:mainfrom
thelastbackspace:fix/4366-repr-c-enum

Conversation

@thelastbackspace

Copy link
Copy Markdown

Does your PR solve an issue?

fixes #4366

The enum derive picked the first path-only item in #[repr(..)] as the integer type to encode through. With #[repr(C)] that ended up as C, so the expansion had MyEnum::A as C and C: Encode<..> bounds and failed to compile.

Now only integer reprs (u8..u128, i8..i128, usize, isize) are picked up. Anything else (C, Rust, transparent) is skipped, so an enum with just #[repr(C)] is handled the same way as one with no repr, which means it's a string enum. Integer-repr enums work like before.

I added a sqlite derive test with a #[repr(C)] enum. Before the change it doesn't compile (unexpected #[sqlx(c = ..)] plus the missing trait impls), and with the change it round-trips as text.

Is this a breaking change?

No. Before this change these enums didn't compile at all.

… for enums

The derive took the first path-only item of #[repr(..)] as the integer type, so #[repr(C)] produced `as C` casts that don't compile. Only use integer reprs; anything else is treated like an enum without a repr.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

repr(C) breaks sqlx::Type on enums

1 participant