[aliceagain]

This fixes an issue where a derive helper attribute is reordered to before the derive block causing a compiler error.

#[repr(u8)]
#[open_enum]
#[derive(CustomDerive, Clone, Copy, Debug, PartialEq, Eq, Default)]
#[custom_attr(test = 2)]
pub enum Example {
...
}

error: derive helper attribute is used before it is introduced
...
   |
47 | #[derive(CustomDerive, Clone, Copy, Debug, PartialEq, Eq, Default)]
   |          -------- the attribute is introduced here
48 | #[custom_attr(test = 2)]
   |   ^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>
   = note: `#[deny(legacy_derive_helpers)]` (part of `#[deny(future_incompatible)]`) on by default

[kupiakos]

Thanks for contributing! Can you A) rebase to the new main and B) include a test that reproduces the error and fails unless you include your functional change?

CI should be fixed now.

[aliceagain]

Change removed:

error: derive helper attribute is used before it is introduced
  --> tests/derives.rs:96:3
   |
95 | #[derive(WithTestAttr)]
   |          ------------ the attribute is introduced here
96 | #[test_attr]
   |   ^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>
   = note: `#[deny(legacy_derive_helpers)]` (part of `#[deny(future_incompatible)]`) on by default

error: could not compile `open-enum` (test "derives") due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Had to create a proc-macro crate to test the behavior, let me know if you'd prefer a different approach. Thanks!

[kupiakos]

Had to create a proc-macro crate to test the behavior, let me know if you'd prefer a different approach

Ah, that does make sense though does make it more difficult to make this crate crater-testable.

I'm already pulling in zerocopy as a dev-dependency (with known desired compatibility). I've just updated the zerocopy in main to 0.8, which grants a #[zerocopy(crate = "...")] attribute that is recognized by its derive macros. That should be able to replace the utility proc-macro crate as long as you give the test enum an explicit repr.

Can you merge/rebase that the new main and use zerocopy instead? Once this is merged I'll publish a new version of open-enum to crates.io.

[aliceagain]

Updated!

[kupiakos]

@aliceagain Now published as version 0.5.3.

Thanks for the fix!