Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking changes in the last version upgrade #314

Closed
oxarbitrage opened this issue Mar 15, 2023 · 3 comments
Closed

Breaking changes in the last version upgrade #314

oxarbitrage opened this issue Mar 15, 2023 · 3 comments

Comments

@oxarbitrage
Copy link

Hey, thank you for the hard work. I am having similar issues as described here. Maybe someone can help.

As it was explained there, it seems Debug is not derived automatically anymore in the new version, this ends up with a compiler error when building our project

The flags code is here.

If i do #[derive(Clone, Debug, PartialEq, Eq, Deserialize, Serialize)] as needed the compiler complains:

error[E0277]: the trait bound `orchard::shielded_data::_::InternalBitFlags: Deserialize<'_>` is not satisfied
   --> zebra-chain/src/orchard/shielded_data.rs:211:1
    |
211 | / bitflags! {
212 | |     /// Per-Transaction flags for Orchard.
213 | |     ///
214 | |     /// The spend and output flags are passed to the `Halo2Proof` verifier, which verifies
...   |
234 | |     }
235 | | }
    | |_^ the trait `Deserialize<'_>` is not implemented for `orchard::shielded_data::_::InternalBitFlags`
    |
    = help: the following other types implement trait `Deserialize<'de>`:
              &'a Path
              &'a [u8]
              &'a str
              ()
              (T0, T1)
              (T0, T1, T2)
              (T0, T1, T2, T3)
              (T0, T1, T2, T3, T4)
            and 286 others
    = note: this error originates in the macro `__declare_public_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

Another thing that worries me is that according to comments above it seems the formatting changed at serialization/deserialization ? This could be a big issue for us as we need to keep the same format as it was before.
It seems that could get resolved by the use of #[repr(transparent)], #[serde(transparent)]?

Thanks in advance.

@KodrAus
Copy link
Member

KodrAus commented Mar 15, 2023

Hi @oxarbitrage 👋

There are some fairly major changes in 2.0.0, we're working on improving the release notes to better reflect them in #310. The bitflags! macro no longer derives any traits that you can do so yourself, so that users get a chance to change the semantics of them.

The derived serialization format has changed, so if you want to maintain compatibility with the old format, I've put together a library that does it for you: https://github.com/KodrAus/bitflags-serde-legacy.

Thanks for persisting through this 🙇

@MarijnS95
Copy link

Can perhaps be closed as duplicate of #310, especially now that the changelog in the tagged release has been improved.

@KodrAus
Copy link
Member

KodrAus commented Apr 2, 2023

I think so 👍 Let's move any further discussion over to #310

@KodrAus KodrAus closed this as completed Apr 2, 2023
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

No branches or pull requests

3 participants