deprecated variants trigger lint rules

[mhelsley]

Marking a variant of an enum as deprecated seems to cause binrw macros to create code that triggers lint rules.

It makes sense to document these enum variants as deprecated so that:

• Any data encountered in the future can be reported as using deprecated features/whatnot and, depending on whether the deprecation is completed, the code can still honor the deprecated variant or refuse in a way that external code and/or users can cogently respond to.
• Any code in the future can treat these values as reserved. This prevents confusion between future added features and old deprecated features.

Marking the whole binrw-wrapped enum with #[expect(deprecated)] does not silence the lint.

Ideal solution (may not be feasible):

• binrw would parse the #[deprecated(..)] attribute for enum variants and apply #[expect(deprecated)] anywhere the variant is read/written.

Other:

• A catch-all binrw item-level attribute which applies allow/expect/deny linting attributes to all the binrw code for the item. e.g. #[brw(allow(deprecated), allow(non_snake_case), ...)]

Unfortunately my Rust proc macro skills aren't up to verifying that this is triggering the lint rules and modifying binrw to guage how feasible any of these "solution" ideas might be.

[csnover]

Thanks for your report!

This appears to happen only when using the non-derive macros, which is confusing since cargo expand output appears to be identical. I am not sure I have the perspicacity to think about what that means right now. I guess that rustc is doing something special.

At least if you are not using the features which aren’t supported by derive, it seems like you can just… do that? Otherwise, if you are seeing this when using #[derive] too, could you please paste an example here? Thanks!