-
Notifications
You must be signed in to change notification settings - Fork 161
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
[proptest-macro] add the ability to specify custom strategies #523
base: main
Are you sure you want to change the base?
[proptest-macro] add the ability to specify custom strategies #523
Conversation
Meta::NameValue(_) => { | ||
if first_strategy_seen { | ||
error.extend(quote_spanned! { | ||
attr.span() => compile_error!("duplicate `#[strategy = ...]` definition"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be worth saying the name of the parameter here for added clarity
snapshot_test!(custom_strategy { | ||
fn foo( | ||
#[strategy = 123] x: i32, | ||
#[strategy = a + more()("complex") - expression!()] y: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is really cool that one can just assign a literal if needed. i'm curious about y
here though, like what happens if an operator that cannot be used on string types is used? I guess that question may reduce down to, what happens if the strategies type does not match the type of the parameter, will the type error be relatively obvious for the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also do we expect argument types to ever use lifetimes or generics? what happens if someone tries to and should we test for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
had a few questions but overall this looks great to me and happy to move forward with it! (assuming ci is 💚 after running)
also just to weigh in a comment from the original pr
I think for now, disallowing other attributes is safer from a backwards compatibility point of view - we don't lock ourselves into supporting something that is difficult later
i think i agree with taking a conservative/iterative stance here
replaces #478