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
requires
is bypassed when other items from a mutually-exclusive group
are present
#4707
Comments
I think this is a duplicate of #4520. If not, let us know in what way it is different and we can re-open |
Hmmm, I had found that issue when searching, but I'm not sure if it's the same thing. #4520 is triggered when you use It may be that it's the same issue under the hood, but I don't know enough about Clap internals to say for sure. |
They are both forms of conflicts but I've re-opened this for the sake of making sure we have tests for both use cases. |
Same problem. |
requires
will accept any item from a group
requires
is bypassed when other items from a mutually-exclusive group
are present
I had the same problem, but I was able to sort-of solve it by lifting the branch that admits options into its own struct. Something like this: use clap::{ArgGroup, Args, Parser};
#[derive(Args, Debug)]
struct Foo {
#[arg(long)]
foo: String,
#[arg(long, requires = "foo")]
quux: Option<String>,
}
#[derive(Debug, Parser)]
#[command(group = ArgGroup::new("mx")
.multiple(false)
.required(true)
.args(&["foo", "bar"])
)]
struct Cli {
#[command(flatten)]
foo_w_option: Option<Foo>,
#[arg(long)]
bar: Option<String>,
}
fn main() {
let args = Cli::parse();
println!("{args:?}");
} I say "sort-of" solve it because, while the parser correctly forbids the
This is actually OK -- although I would expect to see |
* Note about not using infer_subcommands * --tolerate-parsing-errors doesn't make sense for visualisation * Separate out input source types so we can create a unified interface * Fallback to the given output path if canonicalisation fails Resolves #588 * We're going to need an InputFile, too * WIP: InputFile type * Correct blunder regarding --query Note that clap doesn't support (--foo [--bar] | --quux) groups very cleanly; it was a bit of a hack to get this to work, with the result being the error text being a bit off when an illegal combination is attempted. I've attempted to compensate for this by making the long help text quite explicit. Also updated clap, which contains the fix for clap-rs/clap#5022 * Missed change to README * Add note RE clap-rs/clap#4707 workaround * Machinery to unify inputs + downstream use to reimplement visualisation * Don't flatten-away errors * Don't open the input file until we need to read from it * Into InputFrom should be from &AtLeastOneInput * Add logging * Moar logging!1!!
Please complete the following tasks
Rust Version
rustc 1.65.0 (897e37553 2022-11-02)
Clap Version
4.1.4
Minimal reproducible code
Steps to reproduce the bug with the above code
Actual Behaviour
This command runs without an error. This is surprising, because
--show-hex
is annotated withrequires = "read"
, and we did not provide the--read
argument.Expected Behaviour
Clap should print an error indicating that the required argument
--read
is not present, e.g.Additional Context
If I remove either
read
orwrite
from the command group, then everything behaves as expected. This suggests to me that Clap is accepting any member of the command group, instead of the one specifically named in therequires
annotation.Debug Output
The text was updated successfully, but these errors were encountered: