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
arg!(--long-arg "foo")
doesn't behave in expected way
#3586
Comments
This seems to be a limitation of macro-rules that I couldn't find a way around. You need to quote the long option
|
I found the |
which is why this issue is open but I'm not aware of any good solution. Also, we have resigned ourselves in general to not being able to turn every error into a compile error but backstop with debug asserts. We encourage people to add a test that calls |
@epage I guess one solution could be to allow defining short and long flags only in one exact order (-f --flag) |
@evgeniy-terekhin I think I'm missing something with your suggestion. We do only allow one order the problem is I didn't see a way to enforce that in macro rules without blowing up the number of cases we define and I didn't see a way for that to allow |
@epage well I duess I made this suggestion without giving it a proper thought. |
Yes, my guess is that will be the only way forward for improving this macro. While that might seem counter to one of the reasons to use the builder API over the derive (macros hurt build times),. this macro could possibly have no dependencies like xflags |
Please complete the following tasks
Rust Version
rustc 1.54.0
Clap Version
3.1.6
Minimal reproducible code
Steps to reproduce the bug with the above code
Actual Behaviour
Expected Behaviour
The code either builds an argument with long name
--long-option
, or errors at compile time.Additional Context
The issue was found when migrating code from clap 2.
This is a footgun affecting naively ported code that cannot be detected until runtime.
Debug Output
No response
The text was updated successfully, but these errors were encountered: