-
Notifications
You must be signed in to change notification settings - Fork 152
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
Support Option<Option<T>> field types #190
Conversation
you need to rustfmt please. |
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.
Great work! Only a minor stylistic remark.
No problem for the There is no (yet) compile failure tests, so I don't ask to do this. But I'll appreciate a dedicated PR adding this new infrastructure ;-) Noted for the clap problem, can be useful if a related bug report rises. |
Also can you update the CHANGELOG.md? Thanks. |
I forgot a last thing: this feature must be documented. |
I've fixed everything you mentioned. Not sure about CHANGELOG format: should it be under a new version header? For now I've just added a new item on the very top without the version header. I can bump the package version as well (but perhaps you'd like to merge other pull requests first). Thanks for your feedback! |
Thanks! |
v0.2.16 published |
Closes #188
I used
sub_type
function inAttrs
module, so I moved it to there and exported so that it can be reused inlib.rs
, I am not sure this is an optimal solution, please let me know if you want to change that (for example to have a separate module for types manipulations or anything else).Another thing that I wanted to add to tests: is to make sure that
Option<Option<T>>
cannot be used for positional arguments. In this case I would expect a macro code-generation to fail, but I'm not sure how to make a test which expects particular macro failure. For now, I just checked that it works manually.Also please note that I am using
max_values=1
as well asmin_values=0
to limit number of values to 1 in the generatedclap
code. However, handling ofmax_option
inclap
apparently has a bug: it tries to consume one more argument than it should during the parsing.I fixed that bug and prepared a PR here: clap-rs/clap#1481
However, before that bug is fixed, theoretically we can have problems if, say,
Option<Option<T>>
long field with a value is immediately followed by a subcommand, like this:then
clap
(without my fix) would continue consuming arguments for--field
even whenmax_values=1
is set, so it will consume subcommandadd
as well and parsing will fail on seeing-p
. But this is not directly related toOption<Option<T>>
feature, just something to keep mind since it's related tomax_values
.Please let me know if you have any suggestions about the code.