feat: support zeroize codegen #100
Conversation
Cargo.toml
Outdated
| derive = ["byteorder", "ff_derive"] | ||
| std = ["alloc"] | ||
| # with MSRV 1.60 this could be merged into bits with ff_derive?/bits | ||
| # see PR#72 for more information. | ||
| derive_bits = ["bits", "ff_derive/bits"] | ||
| derive_bits = ["bits", "derive", "ff_derive/bits"] | ||
| derive_zero = ["zero", "derive", "ff_derive/zero"] |
There was a problem hiding this comment.
Unlike above, we do need the ability to enable the ff_derive feature flag for tests. I'm inclined to do so via a dedicated test feature flag:
| derive_zero = ["zero", "derive", "ff_derive/zero"] | |
| test-derive = ["derive", "ff_derive/zeroize"] |
There was a problem hiding this comment.
I went with test_derive_zeroize, but I can change that if you want.
Co-authored-by: str4d <[email protected]>
Co-authored-by: str4d <[email protected]>
|
I realized the MSRV Also, let me know if you want me to add Daniel-Aaron-Bloom@485adc5 to this PR. |
|
The MSRV 1.60 bump is indeed easy inside this crate, but imposes restrictions on the rest of the ecosystem. With this being a somewhat foundational crate, we want to be a bit more conservative with MSRV bumps (1.56 was necessary due to the bitvec dependency in the public API). So we're unlikely to bump to 1.60 until we've checked that our downstream users are happy with that (e.g. by themselves all having 1.60+ MSRVs). |
Co-authored-by: str4d <[email protected]>
|
Ping. |
Also, I think
derive_bitsshould enablederive. May be moot after the1.60bump.