-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Flatten structs causes "Argument group name must be unique" if has same name #4279
Comments
This group was added so we could implement
When we implement #3165, we should allow people to rename the implicit group which would be a work around for this that is less disruptive than renaming a type. As for making this work automatically, I do not have any thoughts / plans for that. |
Thanks. So to confirm, the only current solution is to rename the struct in the code so one doesn't have 2 or more structs with the same name if using flattening? |
For now, yes. If you want, you can wait to upgrade until we implement #3165 to have another workaround. |
While upgrading to In short, we use #[derive(Args, Debug)]
pub struct Compose<L: Args, R: Args> {
#[clap(flatten)]
pub left: L,
#[clap(flatten)]
pub right: R,
} This #[derive(Args, Clone, Copy, Debug)]
pub struct Empty; So we quickly get |
Hmmm... what if?
|
Thanks for sharing this use case! Instead of prioritizing other group work, I think i'll focus on
Users are also expected to be able to identify and use the group name which means it needs to be easily discoverable. I'd worry that using the
For now, all groups are empty as I wanted to reserve the names in a breaking release for implementing #3165. Even after that, while |
This was prioritized to allow users to workaround problems when the implicit `ArgGroup` is getting in the way. Fixes clap-rs#4279
4.0.6 is released with |
big thanks! that solved our last remaining issue with clap v4 |
Please complete the following tasks
Rust Version
rustc 1.64.0 (a55dd71d5 2022-09-19)
Clap Version
4.0.1
Minimal reproducible code
Steps to reproduce the bug with the above code
cargo run
Actual Behaviour
The above causes panic on:
due to the two
Config
structs having the same name. Maybe caused internally by these being placed in separate argument groups but with the same argument group names instead of being merged together to a single argument group with then name "Config"?The code
Expected Behaviour
Would want this to work out of the box without having to rename the types
Additional Context
No response
Debug Output
The text was updated successfully, but these errors were encountered: