-
Notifications
You must be signed in to change notification settings - Fork 143
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
Add an "impl_arbitrary" feature to enable implementing Arbitrary
.
#260
Conversation
We might want to reexport |
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
This enables impl_arbitrary when example_generated is enabled.
Drop the "impl_arbitrary" feature, now that we can just use "arbitrary".
I've now implemented this. |
I found an issue with the compile-pass test: EDIT: The test seems to work when adding |
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
And make the other changes suggested by @konsumlamm.
I've now moved the test and made the changes you suggested. |
Thanks for working on this @sunfishcode! It looks like we're failing in CI on our no-std and MSRV targets, which pull in the Maybe what we could do is avoid adding |
Add it to the docs.rs enabled features instead, as suggested in the PR comments.
Sounds good; I've now implemented this. |
Then we need to enable the |
Enabled. |
Are there any other changes that would be helpful to make here? |
Thanks for working on this @sunfishcode! 🙇 Sorry to shift the goalposts at the very end like this, but just before we merge this in, I'd like to make sure we've explored all the space and understand any kind of precedent we're setting. It might be nice to get some thoughts from @Manishearth or @fitzgen too. In For bitflags! {
#[derive(Arbitrary)]
// Would `IncorrectFormat` be a reasonable `with_optional_error` default so we could elide it?
#[arbitrary(arbitrary_optional = "Flags::from_bits", arbitrary_optional_error = "arbitrary::Error::IncorrectFormat")]
struct Flags: u32 {
const A = 1;
const B = 2;
const C = 4;
const D = 8;
}
} where fn arbitrary_optional<'a, A: Arbitrary<'a>, T>(input: A) -> Option<T>; to make the signature of fn from_bits(bits: u32) -> Option<Flags>; That's shifting the design questions from All that's to say I don't think we're blocked on merging this, but want to make sure we're totally comfortable with the approach (and with not accepting it as blanket precedent for an indefinite list of other traits that could be considered). |
Unsure, that attribute doesn't really make sense to have in |
Yeah, having the Better to have it as something you opt into in the macro invocation, not just via cargo feature. One reason I could imagine wanting to manually implement |
Hmm, It might be best to hold off on this and look at other avenues. We could try poking into any bitflags! {
#[derive(Debug)] // standard derive
#[bitflags::derive(TryFrom, Arbitrary)] // traits that can be derived knowing the target is a flags type
pub struct MyFlags: i32 { .. }
} We could even do that as an independent crate for a start. |
Thanks again for working on this @sunfishcode! Now that #220 is merged we could look at a generic approach that could support building flags from any We'll still have the papertrail from the original issue back to the implementation here for anybody that wanted to follow along. |
Fixes #248.