should global options be allowed when args_conflicts_with_subcommands?

[MichalMaruska]

I want to support this usage:

 Usage: tool [GLOBAL OPTIONS] [argument]
        tool [GLOBAL OPTIONS]   <COMMAND>  [CMD OPTIONS] 

That is by this code:

use clap::{Parser, Subcommand};
use std::path::PathBuf;  // not important

#[derive(Parser)]
#[command(version, about, long_about = None)]
#[command(args_conflicts_with_subcommands = true)]
struct Cli {

    // say the Git directory
    #[arg(long, short='g')]
    #[arg(global=true)]
    directory: Option<PathBuf>,

    start: Option<String>,  // this is the original way of using this tool

    #[command(subcommand)]  // this tool is expanded by alternative CLI, command being triggered by options:  -d | --delete etc.
    command: Option<Commands>,
}


#[derive(Subcommand, Debug)]
enum Commands {
    #[command(short_flag('d'))]
    Delete,
}


fn main() {
    let cli = Cli::parse();

    if let Some(argument) = cli.start {
        println!("old processing {}", argument);
    } else if let Some(argument) = cli.command {
        println!("cmd {:?}", argument);
    } else {
        println!("no action");
    }
}

Use cases

tool -g . argument
tool -d -g ./

The following should not be valid:

tool argument -d

args_conflicts_with_subcommands indeed makes it fail. But this (args_conflicts_with_subcommands_set) also prevents using the -g option before the sub-command:

tool -g ./ -d

unfortunately fails, with a panic. But I would want it to pass, not error.

Patch to enable it

I claim that there is even an undeserved panic ....
args_conflicts_with_subcommands_set triggers checks and error message composition can fail
447f3dd

I tried to exclude global options as exception to the "conflict", in this patch:

9fbca3b

Not having read the whole parse() yet, I am not sure if it's correct -- not breaking other features/use-cases.

[epage]

#6184 fixes the panic

Unsure if we should relax the validation around globals. Feel free to create an issue and we can discuss it further.