-
Notifications
You must be signed in to change notification settings - Fork 130
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
zeroize: wasm v128
, more aarch64 registers, const Zeroizing::new()
#964
Conversation
- The rationale behind this is that the MSRV is `1.60`, and `aarch64` SIMD register support was added in `1.59`. - The documentation regarding clearing registers was outdated as this crate and Rust have supported it for quite some time.
v128
, clippy overhaul, const
Zeroizing::new()
, doc fixes, more aarch64 registersv128
, clippy overhaul, const
Zeroizing::new()
, doc fixes, more aarch64 registers
v128
, clippy overhaul, const
Zeroizing::new()
, doc fixes, more aarch64 registersv128
, more aarch64 registers, const Zeroizing::new()
This is a lot of different types of changes in a single PR. I would suggest splitting them up largely around the bullet points you outlined in the original description.
The |
7a0d56e
to
3c7bebd
Compare
That is beyond fair and I honestly kind of expected it: quite a large PR for such a small crate, and the breaking changes were definitely a stretch considering how long it's been at 1.0. I'll close this PR, split everything down, exclude the breaking changes/MSRV bump and hopefully things will be good to go. |
This includes:
wasm
'sv128
SIMD registerAarch64
int*
,float*
andpoly*
registersaarch64
feature (and the corresponding docs) as the MSRV was above that required bycore::arch::aarch64
(breaking change)#[allow(...)]
s where appropriate (wildcard imports and inline always)Zeroizing::new()
is nowconst
(required MSRV bump to 1.61 - breaking change)I attempted to add feature-gated support for
__m512*
registers but it was only stabilized in 1.73.0, and even with some#[cfg]
s, I couldn't get anything working on my 7950x (which has more than enough AVX512 support). It would've been a nice touch considering the rest of the breaking changes.I could attempt to implement the changes brought up in #841
but maybe by XORing the value with itself within an ASM block or something similar?not really viable due to the generic-ness of the implementation.I can always revert the two breaking changes - they're not super important but
const Zeroizing::new()
is quite nice, at not a great cost.