-
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
Macro expansion order appears to cause failure with order-dependent configurations #171
Comments
If no other method in clap need to be at the end, then we can change it to be at the begining. But I suspect that's not the case. If that's not the case, it would need some special attribute, as |
Using
which suggests that we also need an |
Actually I can get the behaviour I need in this specific case using the techniques from #151, marking the group on each argument rather than in an |
@chriskrycho @kw217 @TeXitoi I don't believe macro expansion order can affect this. Let's consider this code (repo:
structopt generates something like this (the snipped is quite long, explanation is on the way)
when we use
What would have change if macro expansion order is reversed? Only This is why I believe this bug is caused by some code in methods generating. Can anyone provide a specific code snipped that would reproduce the issue? Bonus points if it works on current |
I think the problem is not about macro expantion, it's that attribute are stacked before or after adding args, and some app commands need to be called on the other side. |
As far as I get it from the code, this never happens. That's why I'm asking for a reproducer, I almost believe this is already solved |
@TeXitoi I suggest to close this unless someone can show a reproducer. I'm sure this was solved somewhere half-way through the v0.3 |
Using the
AppSettings::VersionlessSubcommand
setting requires that it be set prior to any subcommands being defined. Usingraw(setting = "structopt::clap::AppSettings::VersionlessSubcommands"),
on a top-level struct does not work, however, which implies that the expansion order is probably generating the Subcommand invocations prior to the app settings being applied.The text was updated successfully, but these errors were encountered: