Inline type defining macros, avoid use of cbindgen parse.expand + nightly

[cpu]

We have a small collection of macro_rules! macros that define types: one helper making a u32 rustls_result enum, and a handful for defining opaque structs implementing Castable.

These are handy, but they require we use cbindgen's parse.expand functionality. This in turn requires the nightly toolchain to allow cbindgen to expand the macro definitions before generating the .h file. This worked OK for a while, but nightly broke the handling of cfg feature guards way back in April, requiring that contributors + CI both pin to nightly-2025-03-25.

Since the bug I opened upstream (rust-lang/rust#139715) hasn't received any significant attention in months let's stop using macros in this context so we can go back to cbindgen without parse.expand and the stable toolchain. We can't stay pinned to nightly-2025-03-25 forever.

[djc]

LGTM!

[ctz]

I would be tempted to take a dependency instead of this, honestly. Either we could use https://docs.rs/macro_rules_attribute/latest/macro_rules_attribute/ -- keeping the macro and applying it in proc-macro style, which should work with cbindgen(?) -- or maybe https://crates.io/crates/num-derive or another option that @djc will surely know.

Another alternative is to write a test that checks x == rustls_result::from(x as u32) for most values of x, but that's a bit annoying because the range is sparse.

[cpu]

We were using num_enum originally, and removed it in #322

It doesn't feel to me like the pain of keeping these in-sync justifies a dependency. Is your main concern that we'll get the mapping wrong in the From impl without noticing?

[cpu]

we could use https://docs.rs/macro_rules_attribute/latest/macro_rules_attribute/ -- keeping the macro and applying it in proc-macro style, which should work with cbindgen(?)

That approach seems a little nicer than a numeric enum dependency but I'll have to experiment.

[ctz]

Yeah my main concern is a maintainability one -- that it's easy to add a new enum without adding the reverse mapping.

[djc]

Can we just write a round tripping test?

[cpu]

Can we just write a round tripping test?

Is there a way to write that test without creating even more overhead for adding a new enum variant? That seems like the main hangup with that idea from my perspective.

[djc]

Something like this?

for i in 0..8000 {
     assert_eq!(rustls_result::from(i) as u32, i);
}

[cpu]

@ctz Would a test like ^ be sufficient from your perspective or do you think we need to switch to a proc-macro solution or a full int-enum dep?

[ctz]

That test is tricky because this mapping is not bijective. So 6999u32 maps to rustls_result::InvalidParameter, which maps to 7009u32. And you can't just say "ignore everything that maps to InvalidParameter, because that is the case where an entry is missing in one table or the other.