clap/tests/derive_ui/enum_variant_not_args.rs

#[derive(clap::Parser)]
enum Opt {
    Sub(SubCmd),
}

#[derive(clap::Parser)]
enum SubCmd {}

fn main() {}
fix(derive)!: Rename `Clap` to `Parser`. Before #2005, `Clap` was a special trait that derived all clap traits it detected were relevant (including an enum getting both `ArgEnum`, `Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`, `Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't very descriptive. This also helps further clarify the relationships so a crate providing an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely to choose the needed trait to derive. Also, my proposed fix fo #2785 includes making `App` attributes almost exclusively for `Clap`. Clarifying the names/roles will help communicate this. For prior discussion, see #2583 2021-07-13 17:50:55 +00:00			`#[derive(clap::Parser)]`
chore(derive): Ensure license is recorded for subcommand 2021-07-15 16:43:34 +00:00			`enum Opt {`
			`Sub(SubCmd),`
			`}`

fix(derive)!: Rename `Clap` to `Parser`. Before #2005, `Clap` was a special trait that derived all clap traits it detected were relevant (including an enum getting both `ArgEnum`, `Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`, `Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't very descriptive. This also helps further clarify the relationships so a crate providing an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely to choose the needed trait to derive. Also, my proposed fix fo #2785 includes making `App` attributes almost exclusively for `Clap`. Clarifying the names/roles will help communicate this. For prior discussion, see #2583 2021-07-13 17:50:55 +00:00			`#[derive(clap::Parser)]`
chore(derive): Ensure license is recorded for subcommand 2021-07-15 16:43:34 +00:00			`enum SubCmd {}`

			`fn main() {}`