studio/cli
2
0
Fork 0
Code Issues Pull Requests Actions Packages Releases 4 Wiki Activity

chore: checkpoint before Python removal

Browse Source
This commit is contained in:
Sienna Meridian Satterwhite
2026-03-26 22:33:59 +00:00
parent 683cec9307
commit e568ddf82a
29972 changed files with 11269302 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

108
vendor/clap/src/_concepts.rs vendored Normal file
View File

@@ -0,0 +1,108 @@
//! ## CLI Concepts
//!
//! Note: this will be speaking towards the general case.
//!
//! ### Environmental context
//!
//! When you run a command line application, it is inside a terminal emulator, or terminal.
//! This handles integration with the rest of your system including user input,
//! rendering, etc.
//!
//! The terminal will run inside of itself an interactive shell.
//! The shell is responsible for showing the prompt, receiving input including the command you are writing,
//! letting that command take over until completion, and then repeating.
//! This is called a read-eval-print loop, or REPL.
//! Typically the shell will take the command you typed and split it into separate arguments,
//! including handling of quoting, escaping, and globbing.
//! The parsing and evaluation of the command is shell specific.
//! The shell will then determine which application to run and then pass the full command-line as
//! individual arguments to your program.
//! These arguments are exposed in Rust as [`std::env::args_os`].
//!
//! Windows is an exception in Shell behavior in that the command is passed as an individual
//! string, verbatim, and the application must split the arguments.
//! [`std::env::args_os`] will handle the splitting for you but will not handle globs.
//!
//! Takeaways:
//! - Your application will only see quotes that have been escaped within the shell
//! - e.g. to receive `message="hello world"`, you may need to type `'message="hello world"'` or `message=\"hello world\"`
//! - If your applications needs to parse a string into arguments,
//! you will need to pick a syntax and do it yourself
//! - POSIX's shell syntax is a common choice and available in packages like [shlex](https://docs.rs/shlex)
//! - See also our [REPL cookbook entry][crate::_cookbook::repl]
//! - On Windows, you will need to handle globbing yourself if desired
//! - [`wild`](https://docs.rs/wild) can help with that
//!
//! ### Argument Parsing
//!
//! The first argument of [`std::env::args_os`] is the [`Command::bin_name`]
//! which is usually limited to affecting [`Command::render_usage`].
//! [`Command::no_binary_name`] and [`Command::multicall`] exist for rare cases when this assumption is not valid.
//!
//! Command-lines are a context-sensitive grammar,
//! meaning the interpretation of an argument is based on the arguments that came before.
//! Arguments come in one of several flavors:
//! - Values
//! - Flags
//! - Subcommands
//!
//! When examining the next argument,
//! 1. If it starts with a `--`,
//! then that is a long Flag and all remaining text up to a `=` or the end is
//! matched to a [`Arg::long`], [`Command::long_flag`], or alias.
//! - Everything after the `=` is taken as a Value and parsing a new argument is examined.
//! - If no `=` is present, then Values will be taken according to [`Arg::num_args`]
//! - We generally call a Flag that takes a Value an Option
//! 2. If it starts with a `-`,
//! then that is a sequence of short Flags where each character is matched against a [`Arg::short`], [`Command::short_flag`] or
//! alias until `=`, the end, or a short Flag takes Values (see [`Arg::num_args`])
//! 3. If its a `--`, that is an escape and all future arguments are considered to be a Value, even if
//! they start with `--` or `-`
//! 4. If it matches a [`Command::name`],
//! then the argument is a subcommand
//! 5. If there is an [`Arg`] at the next [`Arg::index`],
//! then the argument is considered a Positional argument
//!
//! When a subcommand matches,
//! all further arguments are parsed by that [`Command`].
//!
//! There are many settings that tweak this behavior, including:
//! - [`Arg::last`]: a positional that can only come after `--`
//! - [`Arg::trailing_var_arg`]: all further arguments are captured as additional Values
//! - [`Arg::allow_hyphen_values`] and [`Arg::allow_negative_numbers`]: assumes arguments
//! starting with `-` are Values and not Flags.
//! - [`Command::subcommand_precedence_over_arg`]: when an [`Arg::num_args`] takes Values,
//! stop if one matches a subCommand
//! - [`Command::allow_missing_positional`]: in limited cases a [`Arg::index`] may be skipped
//! - [`Command::allow_external_subcommands`]: treat any unknown argument as a subcommand, capturing
//! all remaining arguments.
//!
//! Takeaways
//! - Values that start with a `-` either need to be escaped by the user with `--`
//! (if a positional),
//! or you need to set [`Arg::allow_hyphen_values`] or [`Arg::allow_negative_numbers`]
//! - [`Arg::num_args`],
//! [`ArgAction::Append`] (on a positional),
//! [`Arg::trailing_var_arg`],
//! and [`Command::allow_external_subcommands`]
//! all affect the parser in similar but slightly different ways and which to use depends on your
//! application
//!
//! ### Value Parsing
//!
//! When reacting to a Flag (no Value),
//! [`Arg::default_missing_values`] will be applied.
//!
//! The Value will be split by [`Arg::value_delimiter`].
//!
//! The Value will then be stored according to its [`ArgAction`].
//! For most [`ArgAction`]s,
//! the Value will be parsed according to [`ValueParser`]
//! and stored in the [`ArgMatches`].
#![allow(unused_imports)]
use clap_builder::Arg;
use clap_builder::ArgAction;
use clap_builder::ArgMatches;
use clap_builder::Command;
use clap_builder::builder::ValueParser;

7
vendor/clap/src/_cookbook/cargo_example.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: cargo subcommand (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/cargo-example.rs")]
//! ```
//!
#![doc = include_str!("../../examples/cargo-example.md")]

7
vendor/clap/src/_cookbook/cargo_example_derive.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: cargo subcommand (Derive API)
//!
//! ```rust
#![doc = include_str!("../../examples/cargo-example-derive.rs")]
//! ```
//!
#![doc = include_str!("../../examples/cargo-example-derive.md")]

7
vendor/clap/src/_cookbook/escaped_positional.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/escaped-positional.rs")]
//! ```
//!
#![doc = include_str!("../../examples/escaped-positional.md")]

7
vendor/clap/src/_cookbook/escaped_positional_derive.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example (Derive API)
//!
//! ```rust
#![doc = include_str!("../../examples/escaped-positional-derive.rs")]
//! ```
//!
#![doc = include_str!("../../examples/escaped-positional-derive.md")]

7
vendor/clap/src/_cookbook/find.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: find-like CLI (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/find.rs")]
//! ```
//!
#![doc = include_str!("../../examples/find.md")]

7
vendor/clap/src/_cookbook/git.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: git-like CLI (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/git.rs")]
//! ```
//!
#![doc = include_str!("../../examples/git.md")]

7
vendor/clap/src/_cookbook/git_derive.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: git-like CLI (Derive API)
//!
//! ```rust
#![doc = include_str!("../../examples/git-derive.rs")]
//! ```
//!
#![doc = include_str!("../../examples/git-derive.md")]

63
vendor/clap/src/_cookbook/mod.rs vendored Normal file
View File

@@ -0,0 +1,63 @@
// Contributing
//
// New examples:
// - Building: They must be added to `Cargo.toml` with the appropriate `required-features`.
// - Testing: Ensure there is a markdown file with [trycmd](https://docs.rs/trycmd) syntax
// - Link the `.md` file from here
//! # Documentation: Cookbook
//!
//! Typed arguments: [derive][typed_derive]
//! - Topics:
//! - Custom `parse()`
//!
//! Custom cargo command: [builder][cargo_example], [derive][cargo_example_derive]
//! - Topics:
//! - Subcommands
//! - Cargo plugins
//! - custom terminal [styles][crate::Command::styles] (colors)
//!
//! find-like interface: [builder][find]
//! - Topics:
//! - Position-sensitive flags
//!
//! git-like interface: [builder][git], [derive][git_derive]
//! - Topics:
//! - Subcommands
//! - External subcommands
//! - Optional subcommands
//! - Default subcommands
//! - [`last`][crate::Arg::last]
//!
//! pacman-like interface: [builder][pacman]
//! - Topics:
//! - Flag subcommands
//! - Conflicting arguments
//!
//! Escaped positionals with `--`: [builder][escaped_positional], [derive][escaped_positional_derive]
//!
//! Multi-call
//! - busybox: [builder][multicall_busybox]
//! - Topics:
//! - Subcommands
//! - hostname: [builder][multicall_hostname]
//! - Topics:
//! - Subcommands
//!
//! repl: [builder][repl], [derive][repl_derive]
//! - Topics:
//! - Read-Eval-Print Loops / Custom command lines
pub mod cargo_example;
pub mod cargo_example_derive;
pub mod escaped_positional;
pub mod escaped_positional_derive;
pub mod find;
pub mod git;
pub mod git_derive;
pub mod multicall_busybox;
pub mod multicall_hostname;
pub mod pacman;
pub mod repl;
pub mod repl_derive;
pub mod typed_derive;

7
vendor/clap/src/_cookbook/multicall_busybox.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: busybox-like CLI (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/multicall-busybox.rs")]
//! ```
//!
#![doc = include_str!("../../examples/multicall-busybox.md")]

7
vendor/clap/src/_cookbook/multicall_hostname.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: hostname-like CLI (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/multicall-hostname.rs")]
//! ```
//!
#![doc = include_str!("../../examples/multicall-hostname.md")]

7
vendor/clap/src/_cookbook/pacman.rs vendored Normal file
View File

@@ -0,0 +1,7 @@
//! # Example: pacman-like CLI (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/pacman.rs")]
//! ```
//!
#![doc = include_str!("../../examples/pacman.md")]

5
vendor/clap/src/_cookbook/repl.rs vendored Normal file
View File

@@ -0,0 +1,5 @@
//! # Example: Command REPL (Builder API)
//!
//! ```rust
#![doc = include_str!("../../examples/repl.rs")]
//! ```

4
vendor/clap/src/_cookbook/repl_derive.rs vendored Normal file
View File

@@ -0,0 +1,4 @@
//! # Example: REPL (Derive API)
//!
//! ```rust
#![doc = include_str!("../../examples/repl-derive.rs")]

35
vendor/clap/src/_cookbook/typed_derive.rs vendored Normal file
View File

@@ -0,0 +1,35 @@
//! # Example: Custom Types (Derive API)
//!
//! **This requires enabling the [`derive` feature flag][crate::_features].**
//!
//! ## Implicit [`Arg::value_parser`][crate::Arg::value_parser]
//!
//! ```rust
#![doc = include_str!("../../examples/typed-derive/implicit.rs")]
//! ```
//!
#![doc = include_str!("../../examples/typed-derive/implicit.md")]
//!
//! ## Built-in [`TypedValueParser`][crate::builder::TypedValueParser]
//!
//! ```rust
#![doc = include_str!("../../examples/typed-derive/builtin.rs")]
//! ```
//!
#![doc = include_str!("../../examples/typed-derive/builtin.md")]
//!
//! ## Custom parser function
//!
//! ```rust
#![doc = include_str!("../../examples/typed-derive/fn_parser.rs")]
//! ```
//!
#![doc = include_str!("../../examples/typed-derive/fn_parser.md")]
//!
//! ## Custom [`TypedValueParser`][crate::builder::TypedValueParser]
//!
//! ```rust
#![doc = include_str!("../../examples/typed-derive/custom.rs")]
//! ```
//!
#![doc = include_str!("../../examples/typed-derive/custom.md")]

257
vendor/clap/src/_derive/_tutorial.rs vendored Normal file
View File

@@ -0,0 +1,257 @@
// Contributing
//
// New example code:
// - Please update the corresponding section in the derive tutorial
// - Building: They must be added to `Cargo.toml` with the appropriate `required-features`.
// - Testing: Ensure there is a markdown file with [trycmd](https://docs.rs/trycmd) syntax
//
// See also the general CONTRIBUTING
//! ## Tutorial for the Derive API
//!
//! *See the side bar for the Table of Contents*
//!
//! ## Quick Start
//!
//! You can create an application declaratively with a `struct` and some
//! attributes.
//!
//! First, ensure `clap` is available with the [`derive` feature flag][crate::_features]:
//! ```console
//! $ cargo add clap --features derive
//! ```
//!
//! Here is a preview of the type of application you can make:
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/01_quick.rs")]
//! ```
//!
#![doc = include_str!("../../examples/tutorial_derive/01_quick.md")]
//!
//! See also
//! - [FAQ: When should I use the builder vs derive APIs?][crate::_faq#when-should-i-use-the-builder-vs-derive-apis]
//! - The [cookbook][crate::_cookbook] for more application-focused examples
//!
//! ## Configuring the Parser
//!
//! You use derive [`Parser`][crate::Parser] to start building a parser.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/02_apps.rs")]
//! ```
//!
#![doc = include_str!("../../examples/tutorial_derive/02_apps.md")]
//!
//! You can use [`#[command(version, about)]` attribute defaults][super#command-attributes] on the struct to fill these fields in from your `Cargo.toml` file.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/02_crate.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/02_crate.md")]
//!
//! You can use `#[command]` attributes on the struct to change the application level behavior of clap. Any [`Command`][crate::Command] builder function can be used as an attribute, like [`Command::next_line_help`].
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/02_app_settings.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/02_app_settings.md")]
//!
//! ## Adding Arguments
//!
//! 1. [Positionals](#positionals)
//! 2. [Options](#options)
//! 3. [Flags](#flags)
//! 4. [Optional](#optional)
//! 5. [Defaults](#defaults)
//! 6. [Subcommands](#subcommands)
//!
//! Arguments are inferred from the fields of your struct.
//!
//! ### Positionals
//!
//! By default, struct fields define positional arguments:
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_03_positional.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_03_positional.md")]
//!
//! Note that the [default `ArgAction` is `Set`][super#arg-types]. To
//! accept multiple values, override the [action][Arg::action] with [`Append`][crate::ArgAction::Append] via `Vec`:
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_03_positional_mult.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_03_positional_mult.md")]
//!
//! ### Options
//!
//! You can name your arguments with a flag:
//! - Intent of the value is clearer
//! - Order doesn't matter
//!
//! To specify the flags for an argument, you can use [`#[arg(short = 'n')]`][Arg::short] and/or
//! [`#[arg(long = "name")]`][Arg::long] attributes on a field. When no value is given (e.g.
//! `#[arg(short)]`), the flag is inferred from the field's name.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_02_option.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_02_option.md")]
//!
//! Note that the [default `ArgAction` is `Set`][super#arg-types]. To
//! accept multiple occurrences, override the [action][Arg::action] with [`Append`][crate::ArgAction::Append] via `Vec`:
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_02_option_mult.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_02_option_mult.md")]
//!
//! ### Flags
//!
//! Flags can also be switches that can be on/off:
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_01_flag_bool.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_01_flag_bool.md")]
//!
//! Note that the [default `ArgAction` for a `bool` field is
//! `SetTrue`][super#arg-types]. To accept multiple flags, override the [action][Arg::action] with
//! [`Count`][crate::ArgAction::Count]:
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_01_flag_count.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_01_flag_count.md")]
//!
//! This also shows that any[`Arg`][crate::Args] method may be used as an attribute.
//!
//! ### Optional
//!
//! By default, arguments are assumed to be [`required`][crate::Arg::required].
//! To make an argument optional, wrap the field's type in `Option`:
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_06_optional.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_06_optional.md")]
//!
//! ### Defaults
//!
//! We've previously showed that arguments can be [`required`][crate::Arg::required] or optional.
//! When optional, you work with a `Option` and can `unwrap_or`. Alternatively, you can
//! set [`#[arg(default_value_t)]`][super#arg-attributes].
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_05_default_values.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/03_05_default_values.md")]
//!
//! ### Subcommands
//!
//! Subcommands are derived with `#[derive(Subcommand)]` and be added via
//! [`#[command(subcommand)]` attribute][super#command-attributes] on the field using that type.
//! Each instance of a [Subcommand][crate::Subcommand] can have its own version, author(s), Args,
//! and even its own subcommands.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_04_subcommands.rs")]
//! ```
//! We used a struct-variant to define the `add` subcommand.
//! Alternatively, you can use a struct for your subcommand's arguments:
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/03_04_subcommands_alt.rs")]
//! ```
//!
#![doc = include_str!("../../examples/tutorial_derive/03_04_subcommands.md")]
//!
//! ## Validation
//!
//! 1. [Enumerated values](#enumerated-values)
//! 2. [Validated values](#validated-values)
//! 3. [Argument Relations](#argument-relations)
//! 4. [Custom Validation](#custom-validation)
//!
//! An appropriate default parser/validator will be selected for the field's type. See
//! [`value_parser!`][crate::value_parser!] for more details.
//!
//! ### Enumerated values
//!
//! For example, if you have arguments of specific values you want to test for, you can derive
//! [`ValueEnum`][super#valueenum-attributes]
//! (any [`PossibleValue`] builder function can be used as a `#[value]` attribute on enum variants).
//!
//! This allows you specify the valid values for that argument. If the user does not use one of
//! those specific values, they will receive a graceful exit with error message informing them
//! of the mistake, and what the possible valid values are
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/04_01_enum.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/04_01_enum.md")]
//!
//! ### Validated values
//!
//! More generally, you can validate and parse into any data type with [`Arg::value_parser`].
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/04_02_parse.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/04_02_parse.md")]
//!
//! A [custom parser][TypedValueParser] can be used to improve the error messages or provide additional validation:
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/04_02_validate.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/04_02_validate.md")]
//!
//! See [`Arg::value_parser`][crate::Arg::value_parser] for more details.
//!
//! ### Argument Relations
//!
//! You can declare dependencies or conflicts between [`Arg`][crate::Arg]s or even
//! [`ArgGroup`][crate::ArgGroup]s.
//!
//! [`ArgGroup`][crate::ArgGroup]s make it easier to declare relations instead of having to list
//! each individually, or when you want a rule to apply "any but not all" arguments.
//!
//! Perhaps the most common use of [`ArgGroup`][crate::ArgGroup]s is to require one and *only* one
//! argument to be present out of a given set. Imagine that you had multiple arguments, and you
//! want one of them to be required, but making all of them required isn't feasible because perhaps
//! they conflict with each other.
//!
//! [`ArgGroup`][crate::ArgGroup]s are automatically created for a `struct` with its
//! [`ArgGroup::id`][crate::ArgGroup::id] being the struct's name.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/04_03_relations.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/04_03_relations.md")]
//!
//! ### Custom Validation
//!
//! As a last resort, you can create custom errors with the basics of clap's formatting.
//!
//! ```rust
#![doc = include_str!("../../examples/tutorial_derive/04_04_custom.rs")]
//! ```
#![doc = include_str!("../../examples/tutorial_derive/04_04_custom.md")]
//!
//! ## Testing
//!
//! clap reports most development errors as `debug_assert!`s. Rather than checking every
//! subcommand, you should have a test that calls
//! [`Command::debug_assert`][crate::Command::debug_assert]:
//! ```rust,no_run
#![doc = include_str!("../../examples/tutorial_derive/05_01_assert.rs")]
//! ```
//!
//! ## Next Steps
//!
//! - [Cookbook][crate::_cookbook] for application-focused examples
//! - Explore more features in the [Derive reference][super]
//! - See also [`Command`], [`Arg`], [`ArgGroup`], and [`PossibleValue`] builder functions which
//! can be used as attributes
//!
//! For support, see [Discussions](https://github.com/clap-rs/clap/discussions)
#![allow(unused_imports)]
use crate::builder::*;

540
vendor/clap/src/_derive/mod.rs vendored Normal file
View File

@@ -0,0 +1,540 @@
//! # Documentation: Derive Reference
//!
//! 1. [Overview](#overview)
//! 2. [Attributes](#attributes)
//! 1. [Terminology](#terminology)
//! 2. [Command Attributes](#command-attributes)
//! 2. [ArgGroup Attributes](#arggroup-attributes)
//! 3. [Arg Attributes](#arg-attributes)
//! 4. [ValueEnum Attributes](#valueenum-attributes)
//! 5. [Possible Value Attributes](#possible-value-attributes)
//! 3. [Field Types](#field-types)
//! 4. [Doc Comments](#doc-comments)
//! 5. [Mixing Builder and Derive APIs](#mixing-builder-and-derive-apis)
//! 6. [Tips](#tips)
//!
//! ## Overview
//!
//! To derive `clap` types, you need to enable the [`derive` feature flag][crate::_features].
//!
//! Example:
//! ```rust
#![doc = include_str!("../../examples/demo.rs")]
//! ```
//!
//! Let's start by breaking down the anatomy of the derive attributes:
//! ```rust
//! use clap::{Parser, Args, Subcommand, ValueEnum};
//!
//! /// Doc comment
//! #[derive(Parser)]
//! #[command(CMD ATTRIBUTE)]
//! #[group(GROUP ATTRIBUTE)]
//! struct Cli {
//! /// Doc comment
//! #[arg(ARG ATTRIBUTE)]
//! field: UserType,
//!
//! #[arg(value_enum, ARG ATTRIBUTE...)]
//! field: EnumValues,
//!
//! #[command(flatten)]
//! delegate: Struct,
//!
//! #[command(subcommand)]
//! command: Command,
//! }
//!
//! /// Doc comment
//! #[derive(Args)]
//! #[command(PARENT CMD ATTRIBUTE)]
//! #[group(GROUP ATTRIBUTE)]
//! struct Struct {
//! /// Doc comment
//! #[command(ARG ATTRIBUTE)]
//! field: UserType,
//! }
//!
//! /// Doc comment
//! #[derive(Subcommand)]
//! #[command(PARENT CMD ATTRIBUTE)]
//! enum Command {
//! /// Doc comment
//! #[command(CMD ATTRIBUTE)]
//! Variant1(Struct),
//!
//! /// Doc comment
//! #[command(CMD ATTRIBUTE)]
//! Variant2 {
//! /// Doc comment
//! #[arg(ARG ATTRIBUTE)]
//! field: UserType,
//! }
//! }
//!
//! /// Doc comment
//! #[derive(ValueEnum)]
//! #[value(VALUE ENUM ATTRIBUTE)]
//! enum EnumValues {
//! /// Doc comment
//! #[value(POSSIBLE VALUE ATTRIBUTE)]
//! Variant1,
//! }
//!
//! let cli = Cli::parse();
//! ```
//!
//! Traits:
//! - [`Parser`][crate::Parser] parses arguments into a `struct` (arguments) or `enum` (subcommands).
//! - [`Args`][crate::Args] allows defining a set of re-usable arguments that get merged into their parent container.
//! - [`Subcommand`][crate::Subcommand] defines available subcommands.
//! - Subcommand arguments can be defined in a struct-variant or automatically flattened with a tuple-variant.
//! - [`ValueEnum`][crate::ValueEnum] allows parsing a value directly into an `enum`, erroring on unsupported values.
//! - The derive doesn't work on enums that contain non-unit variants, unless they are skipped
//!
//! *See also the [derive tutorial][crate::_derive::_tutorial] and [cookbook][crate::_cookbook]*
//!
//! ## Attributes
//!
//! ### Terminology
//!
//! **Raw attributes** are forwarded directly to the underlying [`clap` builder][crate::builder]. Any
//! [`Command`][crate::Command], [`Arg`][crate::Arg], or [`PossibleValue`][crate::builder::PossibleValue] method can be used as an attribute.
//!
//! Raw attributes come in two different syntaxes:
//! ```rust,ignore
//! #[arg(
//! global = true, // name = arg form, neat for one-arg methods
//! required_if_eq("out", "file") // name(arg1, arg2, ...) form.
//! )]
//! ```
//!
//! - `method = arg` can only be used for methods which take only one argument.
//! - `method(arg1, arg2)` can be used with any method.
//!
//! As long as `method_name` is not one of the magical methods it will be
//! translated into a mere method call.
//!
//! **Magic attributes** have post-processing done to them, whether that is
//! - Providing of defaults
//! - Special behavior is triggered off of it
//!
//! Magic attributes are more constrained in the syntax they support, usually just
//! `<attr> = <value>` though some use `<attr>(<value>)` instead. See the specific
//! magic attributes documentation for details. This allows users to access the
//! raw behavior of an attribute via `<attr>(<value>)` syntax.
//!
//! <div class="warning">
//!
//! **NOTE:** Some attributes are inferred from [Arg Types](#arg-types) and [Doc
//! Comments](#doc-comments). Explicit attributes take precedence over inferred
//! attributes.
//!
//! </div>
//!
//! ### Command Attributes
//!
//! These correspond to a [`Command`][crate::Command] which is used for both top-level parsers and
//! when defining subcommands.
//!
//! **Raw attributes:** Any [`Command` method][crate::Command] can also be used as an attribute,
//! see [Terminology](#terminology) for syntax.
//! - e.g. `#[command(arg_required_else_help(true))]` would translate to `cmd.arg_required_else_help(true)`
//!
//! **Magic attributes:**
//! - `name = <expr>`: [`Command::name`][crate::Command::name]
//! - When not present: [package `name`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field) (if on [`Parser`][crate::Parser] container), variant name (if on [`Subcommand`][crate::Subcommand] variant)
//! - `version [= <expr>]`: [`Command::version`][crate::Command::version]
//! - When not present: no version set
//! - Without `<expr>`: defaults to [crate `version`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field)
//! - `author [= <expr>]`: [`Command::author`][crate::Command::author]
//! - When not present: no author set
//! - Without `<expr>`: defaults to [crate `authors`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field)
//! - **NOTE:** A custom [`help_template`][crate::Command::help_template] is needed for author to show up.
//! - `about [= <expr>]`: [`Command::about`][crate::Command::about]
//! - When not present: [Doc comment summary](#doc-comments)
//! - Without `<expr>`: [crate `description`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-description-field) ([`Parser`][crate::Parser] container)
//! - **TIP:** When a doc comment is also present, you most likely want to add
//! `#[arg(long_about = None)]` to clear the doc comment so only [`about`][crate::Command::about]
//! gets shown with both `-h` and `--help`.
//! - `long_about[ = <expr>]`: [`Command::long_about`][crate::Command::long_about]
//! - When not present: [Doc comment](#doc-comments) if there is a blank line, else nothing
//! - When present without a value: [Doc comment](#doc-comments)
//! - `verbatim_doc_comment`: Minimizes pre-processing when converting doc comments to [`about`][crate::Command::about] / [`long_about`][crate::Command::long_about]
//! - `next_display_order`: [`Command::next_display_order`][crate::Command::next_display_order]
//! - `next_help_heading`: [`Command::next_help_heading`][crate::Command::next_help_heading]
//! - When `flatten`ing [`Args`][crate::Args], this is scoped to just the args in this struct and any struct `flatten`ed into it
//! - `rename_all = <string_literal>`: Override default field / variant name case conversion for [`Command::name`][crate::Command::name] / [`Arg::id`][crate::Arg::id]
//! - When not present: `"kebab-case"`
//! - Available values: `"camelCase"`, `"kebab-case"`, `"PascalCase"`, `"SCREAMING_SNAKE_CASE"`, `"snake_case"`, `"lower"`, `"UPPER"`, `"verbatim"`
//! - `rename_all_env = <string_literal>`: Override default field name case conversion for env variables for [`Arg::env`][crate::Arg::env]
//! - When not present: `"SCREAMING_SNAKE_CASE"`
//! - Available values: `"camelCase"`, `"kebab-case"`, `"PascalCase"`, `"SCREAMING_SNAKE_CASE"`, `"snake_case"`, `"lower"`, `"UPPER"`, `"verbatim"`
//!
//! And for [`Subcommand`][crate::Subcommand] variants:
//! - `skip`: Ignore this variant
//! - `flatten`: Delegates to the variant for more subcommands (must implement
//! [`Subcommand`][crate::Subcommand])
//! - `subcommand`: Nest subcommands under the current set of subcommands (must implement
//! [`Subcommand`][crate::Subcommand])
//! - `external_subcommand`: [`Command::allow_external_subcommand(true)`][crate::Command::allow_external_subcommands]
//! - Variant must be either `Variant(Vec<String>)` or `Variant(Vec<OsString>)`
//!
//! And for [`Args`][crate::Args] fields:
//! - `flatten`: Delegates to the field for more arguments (must implement [`Args`][crate::Args])
//! - Only [`next_help_heading`][crate::Command::next_help_heading] can be used with `flatten`. See
//! [clap-rs/clap#3269](https://github.com/clap-rs/clap/issues/3269) for why
//! arg attributes are not generally supported.
//! - **Tip:** Though we do apply a flattened [`Args`][crate::Args]'s Parent Command Attributes, this
//! makes reuse harder. Generally prefer putting the cmd attributes on the
//! [`Parser`][crate::Parser] or on the flattened field.
//! - `subcommand`: Delegates definition of subcommands to the field (must implement
//! [`Subcommand`][crate::Subcommand])
//! - When `Option<T>`, the subcommand becomes optional
//!
//! See [Configuring the Parser][_tutorial#configuring-the-parser] and
//! [Subcommands][_tutorial#subcommands] from the tutorial.
//!
//! ### ArgGroup Attributes
//!
//! These correspond to the [`ArgGroup`][crate::ArgGroup] which is implicitly created for each
//! `Args` derive.
//!
//! **Raw attributes:** Any [`ArgGroup` method][crate::ArgGroup] can also be used as an attribute, see [Terminology](#terminology) for syntax.
//! - e.g. `#[group(required = true)]` would translate to `arg_group.required(true)`
//!
//! **Magic attributes**:
//! - `id = <expr>`: [`ArgGroup::id`][crate::ArgGroup::id]
//! - When not present: struct's name is used
//! - `skip [= <expr>]`: Ignore this field, filling in with `<expr>`
//! - Without `<expr>`: fills the field with `Default::default()`
//!
//! Note:
//! - For `struct`s, [`multiple = true`][crate::ArgGroup::multiple] is implied
//! - `enum` support is tracked at [#2621](https://github.com/clap-rs/clap/issues/2621)
//!
//! See [Argument Relations][_tutorial#argument-relations] from the tutorial.
//!
//! ### Arg Attributes
//!
//! These correspond to a [`Arg`][crate::Arg].
//! The default state for a field without attributes is to be a positional argument with [behavior
//! inferred from the field type](#arg-types).
//! `#[arg(...)]` attributes allow overriding or extending those defaults.
//!
//! **Raw attributes:** Any [`Arg` method][crate::Arg] can also be used as an attribute, see [Terminology](#terminology) for syntax.
//! - e.g. `#[arg(num_args(..=3))]` would translate to `arg.num_args(..=3)`
//!
//! **Magic attributes**:
//! - `id = <expr>`: [`Arg::id`][crate::Arg::id]
//! - When not present: field's name is used
//! - `value_parser [= <expr>]`: [`Arg::value_parser`][crate::Arg::value_parser]
//! - When not present: will auto-select an implementation based on the field type using
//! [`value_parser!`][crate::value_parser!]
//! - `action [= <expr>]`: [`Arg::action`][crate::Arg::action]
//! - When not present: will auto-select an action based on the field type
//! - `help = <expr>`: [`Arg::help`][crate::Arg::help]
//! - When not present: [Doc comment summary](#doc-comments)
//! - `long_help[ = <expr>]`: [`Arg::long_help`][crate::Arg::long_help]
//! - When not present: [Doc comment](#doc-comments) if there is a blank line, else nothing
//! - When present without a value: [Doc comment](#doc-comments)
//! - `verbatim_doc_comment`: Minimizes pre-processing when converting doc comments to [`help`][crate::Arg::help] / [`long_help`][crate::Arg::long_help]
//! - `short [= <char>]`: [`Arg::short`][crate::Arg::short]
//! - When not present: no short set
//! - Without `<char>`: defaults to first character in the case-converted field name
//! - `long [= <str>]`: [`Arg::long`][crate::Arg::long]
//! - When not present: no long set
//! - Without `<str>`: defaults to the case-converted field name
//! - `env [= <str>]`: [`Arg::env`][crate::Arg::env] (needs [`env` feature][crate::_features] enabled)
//! - When not present: no env set
//! - Without `<str>`: defaults to the case-converted field name
//! - `from_global`: Read a [`Arg::global`][crate::Arg::global] argument (raw attribute), regardless of what subcommand you are in
//! - `value_enum`: Parse the value using the [`ValueEnum`][crate::ValueEnum]
//! - `skip [= <expr>]`: Ignore this field, filling in with `<expr>`
//! - Without `<expr>`: fills the field with `Default::default()`
//! - `default_value = <str>`: [`Arg::default_value`][crate::Arg::default_value] and [`Arg::required(false)`][crate::Arg::required]
//! - `default_value_t [= <expr>]`: [`Arg::default_value`][crate::Arg::default_value] and [`Arg::required(false)`][crate::Arg::required]
//! - Requires `std::fmt::Display` that roundtrips correctly with the
//! [`Arg::value_parser`][crate::Arg::value_parser] or `#[arg(value_enum)]`
//! - Without `<expr>`, relies on `Default::default()`
//! - `default_values_t = <expr>`: [`Arg::default_values`][crate::Arg::default_values] and [`Arg::required(false)`][crate::Arg::required]
//! - Requires field arg to be of type `Vec<T>` and `T` to implement `std::fmt::Display` or `#[arg(value_enum)]`
//! - `<expr>` must implement `IntoIterator<T>`
//! - `default_value_os_t [= <expr>]`: [`Arg::default_value_os`][crate::Arg::default_value_os] and [`Arg::required(false)`][crate::Arg::required]
//! - Requires `std::convert::Into<OsString>` or `#[arg(value_enum)]`
//! - Without `<expr>`, relies on `Default::default()`
//! - `default_values_os_t = <expr>`: [`Arg::default_values_os`][crate::Arg::default_values_os] and [`Arg::required(false)`][crate::Arg::required]
//! - Requires field arg to be of type `Vec<T>` and `T` to implement `std::convert::Into<OsString>` or `#[arg(value_enum)]`
//! - `<expr>` must implement `IntoIterator<T>`
//!
//! See [Adding Arguments][_tutorial#adding-arguments] and [Validation][_tutorial#validation] from the
//! tutorial.
//!
//! ### ValueEnum Attributes
//!
//! - `rename_all = <string_literal>`: Override default field / variant name case conversion for [`PossibleValue::new`][crate::builder::PossibleValue]
//! - When not present: `"kebab-case"`
//! - Available values: `"camelCase"`, `"kebab-case"`, `"PascalCase"`, `"SCREAMING_SNAKE_CASE"`, `"snake_case"`, `"lower"`, `"UPPER"`, `"verbatim"`
//!
//! See [Enumerated values][_tutorial#enumerated-values] from the tutorial.
//!
//! ### Possible Value Attributes
//!
//! These correspond to a [`PossibleValue`][crate::builder::PossibleValue].
//!
//! **Raw attributes:** Any [`PossibleValue` method][crate::builder::PossibleValue] can also be used as an attribute, see [Terminology](#terminology) for syntax.
//! - e.g. `#[value(alias("foo"))]` would translate to `pv.alias("foo")`
//!
//! **Magic attributes**:
//! - `name = <expr>`: [`PossibleValue::new`][crate::builder::PossibleValue::new]
//! - When not present: case-converted field name is used
//! - `help = <expr>`: [`PossibleValue::help`][crate::builder::PossibleValue::help]
//! - When not present: [Doc comment summary](#doc-comments)
//! - `skip`: Ignore this variant
//!
//! ## Field Types
//!
//! `clap` assumes some intent based on the type used.
//!
//! ### Subcommand Types
//!
//! | Type | Effect | Implies |
//! |-----------------------|---------------------|-----------------------------------------------------------|
//! | `Option<T>` | optional subcommand | |
//! | `T` | required subcommand | `.subcommand_required(true).arg_required_else_help(true)` |
//!
//! ### Arg Types
//!
//! | Type | Effect | Implies | Notes |
//! |-----------------------|------------------------------------------------------|-------------------------------------------------------------|-------|
//! | `()` | user-defined | `.action(ArgAction::Set).required(false)` | |
//! | `bool` | flag | `.action(ArgAction::SetTrue)` | |
//! | `Option<T>` | optional argument | `.action(ArgAction::Set).required(false)` | |
//! | `Option<Option<T>>` | optional value for optional argument | `.action(ArgAction::Set).required(false).num_args(0..=1)` | |
//! | `T` | required argument | `.action(ArgAction::Set).required(!has_default)` | |
//! | `Vec<T>` | `0..` occurrences of argument | `.action(ArgAction::Append).required(false)` | |
//! | `Option<Vec<T>>` | `0..` occurrences of argument | `.action(ArgAction::Append).required(false)` | |
//! | `Vec<Vec<T>>` | `0..` occurrences of argument, grouped by occurrence | `.action(ArgAction::Append).required(false)` | requires `unstable-v5` |
//! | `Option<Vec<Vec<T>>>` | `0..` occurrences of argument, grouped by occurrence | `.action(ArgAction::Append).required(false)` | requires `unstable-v5` |
//!
//! In addition, [`.value_parser(value_parser!(T))`][crate::value_parser!] is called for each
//! field in the absence of a [`#[arg(value_parser)]` attribute](#arg-attributes).
//!
//! Notes:
//! - For custom type behavior, you can override the implied attributes/settings and/or set additional ones
//! - To force any inferred type (like `Vec<T>`) to be treated as `T`, you can refer to the type
//! by another means, like using `std::vec::Vec` instead of `Vec`. For improving this, see
//! [#4626](https://github.com/clap-rs/clap/issues/4626).
//! - `Option<Vec<T>>` and `Option<Vec<Vec<T>>` will be `None` instead of `vec![]` if no arguments are provided.
//! - This gives the user some flexibility in designing their argument, like with `num_args(0..)`
//! - `Vec<Vec<T>>` will need [`Arg::num_args`][crate::Arg::num_args] set to be meaningful
//!
//! ## Doc Comments
//!
//! In clap, help messages for the whole binary can be specified
//! via [`Command::about`][crate::Command::about] and [`Command::long_about`][crate::Command::long_about] while help messages
//! for individual arguments can be specified via [`Arg::help`][crate::Arg::help] and [`Arg::long_help`][crate::Arg::long_help].
//!
//! `long_*` variants are used when user calls the program with
//! `--help` and "short" variants are used with `-h` flag.
//!
//! ```rust
//! # use clap::Parser;
//!
//! #[derive(Parser)]
//! #[command(about = "I am a program and I work, just pass `-h`", long_about = None)]
//! struct Foo {
//! #[arg(short, help = "Pass `-h` and you'll see me!")]
//! bar: String,
//! }
//! ```
//!
//! For convenience, doc comments can be used instead of raw methods
//! (this example works exactly like the one above):
//!
//! ```rust
//! # use clap::Parser;
//!
//! #[derive(Parser)]
//! /// I am a program and I work, just pass `-h`
//! struct Foo {
//! /// Pass `-h` and you'll see me!
//! bar: String,
//! }
//! ```
//!
//! <div class="warning">
//!
//! **NOTE:** Attributes have priority over doc comments!
//!
//! **Top level doc comments always generate `Command::about/long_about` calls!**
//! If you really want to use the `Command::about/long_about` methods (you likely don't),
//! use the `about` / `long_about` attributes to override the calls generated from
//! the doc comment. To clear `long_about`, you can use
//! `#[command(long_about = None)]`.
//!
//! </div>
//!
//! ### Pre-processing
//!
//! ```rust
//! # use clap::Parser;
//! #[derive(Parser)]
//! /// Hi there, I'm Robo!
//! ///
//! /// I like beeping, stumbling, eating your electricity,
//! /// and making records of you singing in a shower.
//! /// Pay up, or I'll upload it to youtube!
//! struct Robo {
//! /// Call my brother SkyNet.
//! ///
//! /// I am artificial superintelligence. I won't rest
//! /// until I'll have destroyed humanity. Enjoy your
//! /// pathetic existence, you mere mortals.
//! #[arg(long, action)]
//! kill_all_humans: bool,
//! }
//! ```
//!
//! A doc comment consists of three parts:
//! - Short summary
//! - A blank line (whitespace only)
//! - Detailed description, all the rest
//!
//! The summary corresponds with `Command::about` / `Arg::help`. When a blank line is
//! present, the whole doc comment will be passed to `Command::long_about` /
//! `Arg::long_help`. Or in other words, a doc may result in just a `Command::about` /
//! `Arg::help` or `Command::about` / `Arg::help` and `Command::long_about` /
//! `Arg::long_help`
//!
//! In addition, when `verbatim_doc_comment` is not present, `clap` applies some preprocessing, including:
//!
//! - Strip leading and trailing whitespace from every line, if present.
//!
//! - Strip leading and trailing blank lines, if present.
//!
//! - Interpret each group of non-empty lines as a word-wrapped paragraph.
//!
//! We replace newlines within paragraphs with spaces to allow the output
//! to be re-wrapped to the terminal width.
//!
//! - Strip any excess blank lines so that there is exactly one per paragraph break.
//!
//! - If the first paragraph ends in exactly one period,
//! remove the trailing period (i.e. strip trailing periods but not trailing ellipses).
//!
//! Sometimes you don't want this preprocessing to apply, for example the comment contains
//! some ASCII art or markdown tables, you would need to preserve LFs along with
//! blank lines and the leading/trailing whitespace. When you pass use the
//! `verbatim_doc_comment` magic attribute, you preserve
//! them.
//!
//! **Note:** Keep in mind that `verbatim_doc_comment` will *still*
//! - Remove one leading space from each line, even if this attribute is present,
//! to allow for a space between `///` and the content.
//! - Remove leading and trailing blank lines
//!
//! ## Mixing Builder and Derive APIs
//!
//! The builder and derive APIs do not live in isolation. They can work together, which is
//! especially helpful if some arguments can be specified at compile-time while others must be
//! specified at runtime.
//!
//! ### Using derived arguments in a builder application
//!
//! When using the derive API, you can `#[command(flatten)]` a struct deriving `Args` into a struct
//! deriving `Args` or `Parser`. This example shows how you can augment a `Command` instance
//! created using the builder API with `Args` created using the derive API.
//!
//! It uses the [`Args::augment_args`][crate::Args::augment_args] method to add the arguments to
//! the `Command` instance.
//!
//! Crates such as [clap-verbosity-flag](https://github.com/rust-cli/clap-verbosity-flag) provide
//! structs that implement `Args`. Without the technique shown in this example, it would not be
//! possible to use such crates with the builder API.
//!
//! For example:
//! ```rust
#![doc = include_str!("../../examples/derive_ref/augment_args.rs")]
//! ```
//!
//! ### Using derived subcommands in a builder application
//!
//! When using the derive API, you can use `#[command(subcommand)]` inside the struct to add
//! subcommands. The type of the field is usually an enum that derived `Parser`. However, you can
//! also add the subcommands in that enum to a `Command` instance created with the builder API.
//!
//! It uses the [`Subcommand::augment_subcommands`][crate::Subcommand::augment_subcommands] method
//! to add the subcommands to the `Command` instance.
//!
//! For example:
//! ```rust
#![doc = include_str!("../../examples/derive_ref/augment_subcommands.rs")]
//! ```
//!
//! ### Adding hand-implemented subcommands to a derived application
//!
//! When using the derive API, you can use `#[command(subcommand)]` inside the struct to add
//! subcommands. The type of the field is usually an enum that derived `Parser`. However, you can
//! also implement the `Subcommand` trait manually on this enum (or any other type) and it can
//! still be used inside the struct created with the derive API. The implementation of the
//! `Subcommand` trait will use the builder API to add the subcommands to the `Command` instance
//! created behind the scenes for you by the derive API.
//!
//! Notice how in the previous example we used
//! [`augment_subcommands`][crate::Subcommand::augment_subcommands] on an enum that derived
//! `Parser`, whereas now we implement
//! [`augment_subcommands`][crate::Subcommand::augment_subcommands] ourselves, but the derive API
//! calls it automatically since we used the `#[command(subcommand)]` attribute.
//!
//! For example:
//! ```rust
#![doc = include_str!("../../examples/derive_ref/hand_subcommand.rs")]
//! ```
//!
//! ### Flattening hand-implemented args into a derived application
//!
//! When using the derive API, you can use `#[command(flatten)]` inside the struct to add arguments as
//! if they were added directly to the containing struct. The type of the field is usually an
//! struct that derived `Args`. However, you can also implement the `Args` trait manually on this
//! struct (or any other type) and it can still be used inside the struct created with the derive
//! API. The implementation of the `Args` trait will use the builder API to add the arguments to
//! the `Command` instance created behind the scenes for you by the derive API.
//!
//! Notice how in the previous example we used [`augment_args`][crate::Args::augment_args] on the
//! struct that derived `Parser`, whereas now we implement
//! [`augment_args`][crate::Args::augment_args] ourselves, but the derive API calls it
//! automatically since we used the `#[command(flatten)]` attribute.
//!
//! For example:
//! ```rust
#![doc = include_str!("../../examples/derive_ref/flatten_hand_args.rs")]
//! ```
//!
//! ## Tips
//!
//! - To get access to a [`Command`][crate::Command] call
//! [`CommandFactory::command`][crate::CommandFactory::command] (implemented when deriving
//! [`Parser`][crate::Parser])
//! - Proactively check for bad [`Command`][crate::Command] configurations by calling
//! [`Command::debug_assert`][crate::Command::debug_assert] in a test
//! ([example][_tutorial#testing])
//! - Always remember to [document](#doc-comments) args and commands with `#![deny(missing_docs)]`
// Point people here that search for attributes that don't exist in the derive (a subset of magic
// attributes)
#![doc(alias = "skip")]
#![doc(alias = "verbatim_doc_comment")]
#![doc(alias = "flatten")]
#![doc(alias = "external_subcommand")]
#![doc(alias = "subcommand")]
#![doc(alias = "rename_all")]
#![doc(alias = "rename_all_env")]
#![doc(alias = "default_value_t")]
#![doc(alias = "default_values_t")]
#![doc(alias = "default_value_os_t")]
#![doc(alias = "default_values_os_t")]
pub mod _tutorial;
#[doc(inline)]
pub use crate::_cookbook;

95
vendor/clap/src/_faq.rs vendored Normal file
View File

@@ -0,0 +1,95 @@
//! # Documentation: FAQ
//!
//! 1. [Comparisons](#comparisons)
//! 1. [How does `clap` compare to structopt?](#how-does-clap-compare-to-structopt)
//! 2. [What are some reasons to use `clap`? (The Pitch)](#what-are-some-reasons-to-use-clap-the-pitch)
//! 3. [What are some reasons *not* to use `clap`? (The Anti Pitch)](#what-are-some-reasons-not-to-use-clap-the-anti-pitch)
//! 4. [Reasons to use `clap`](#reasons-to-use-clap)
//! 2. [How many approaches are there to create a parser?](#how-many-approaches-are-there-to-create-a-parser)
//! 3. [When should I use the builder vs derive APIs?](#when-should-i-use-the-builder-vs-derive-apis)
//! 4. [Why is there a default subcommand of help?](#why-is-there-a-default-subcommand-of-help)
//!
//! ### Comparisons
//!
//! First, let me say that these comparisons are highly subjective, and not meant
//! in a critical or harsh manner. All the argument parsing libraries out there (to
//! include `clap`) have their own strengths and weaknesses. Sometimes it just
//! comes down to personal taste when all other factors are equal. When in doubt,
//! try them all and pick one that you enjoy :). There's plenty of room in the Rust
//! community for multiple implementations!
//!
//! For less detailed but more broad comparisons, see
//! [argparse-benchmarks](https://github.com/rust-cli/argparse-benchmarks-rs).
//!
//! #### How does `clap` compare to [structopt](https://github.com/TeXitoi/structopt)?
//!
//! Simple! `clap` *is* `structopt`. `structopt` started as a derive API built on
//! top of clap v2. With clap v3, we've forked structopt and integrated it
//! directly into clap. structopt is in
//! [maintenance mode](https://github.com/TeXitoi/structopt/issues/516#issuecomment-989566094)
//! with the release of `clap_derive`.
//!
//! The benefits of integrating `structopt` and `clap` are:
//! - Easier cross-linking in documentation
//! - Documentation parity
//! - Tighter design feedback loop, ensuring all new features are designed with
//! derives in mind and easier to change `clap` in response to `structopt` bugs.
//! - Clearer endorsement of `structopt`
//!
//! See also
//! - [`clap` v3 CHANGELOG](https://github.com/clap-rs/clap/blob/v3-master/CHANGELOG.md#300---2021-12-31)
//! - [`structopt` migration guide](https://github.com/clap-rs/clap/blob/v3-master/CHANGELOG.md#migrate-structopt)
//!
//! #### What are some reasons to use `clap`? (The Pitch)
//!
//! `clap` is as fast, and as lightweight as possible while still giving all the features you'd expect from a modern argument parser. In fact, for the amount and type of features `clap` offers it remains about as fast as `getopts`. If you use `clap`, when you just need some simple arguments parsed, you'll find it's a walk in the park. `clap` also makes it possible to represent extremely complex and advanced requirements without too much thought. `clap` aims to be intuitive, easy to use, and fully capable for wide variety use cases and needs.
//!
//! #### What are some reasons *not* to use `clap`? (The Anti Pitch)
//!
//! Depending on the style in which you choose to define the valid arguments, `clap` can be very verbose. `clap` also offers so many finetuning knobs and dials, that learning everything can seem overwhelming. I strive to keep the simple cases simple, but when turning all those custom dials it can get complex. `clap` is also opinionated about parsing. Even though so much can be tweaked and tuned with `clap` (and I'm adding more all the time), there are still certain features which `clap` implements in specific ways that may be contrary to some users' use-cases.
//!
//! #### Reasons to use `clap`
//!
//! * You want all the nice CLI features your users may expect, yet you don't want to implement them all yourself. You'd like to focus on your application, not argument parsing.
//! * In addition to the point above, you don't want to sacrifice performance to get all those nice features.
//! * You have complex requirements/conflicts between your various valid args.
//! * You want to use subcommands (although other libraries also support subcommands, they are not nearly as feature rich as those provided by `clap`).
//! * You want some sort of custom validation built into the argument parsing process, instead of as part of your application (which allows for earlier failures, better error messages, more cohesive experience, etc.).
//!
//! ### How many approaches are there to create a parser?
//!
//! The following APIs are supported:
//! - [Derive][crate::_derive::_tutorial]
//! - [Builder][crate::_tutorial]
//!
//! Previously, we supported:
//! - [YAML](https://github.com/clap-rs/clap/issues/3087)
//! - [docopt](http://docopt.org/)-inspired [usage parser](https://github.com/clap-rs/clap/issues/3086)
//! - [`clap_app!`](https://github.com/clap-rs/clap/issues/2835)
//!
//! There are also experiments with other APIs:
//! - [fncmd](https://github.com/yuhr/fncmd): function attribute
//! - [clap-serde](https://github.com/aobatact/clap-serde): create a `Command` from a deserializer
//!
//! ### When should I use the builder vs derive APIs?
//!
//! Our default answer is to use the [Derive API][crate::_derive::_tutorial]:
//! - Easier to read, write, and modify
//! - Easier to keep the argument declaration and reading of argument in sync
//! - Easier to reuse, e.g. [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
//!
//! The [Builder API][crate::_tutorial] is a lower-level API that someone might want to use for
//! - Faster compile times if you aren't already using other procedural macros
//! - More flexibility, e.g. you can look up the [argument's values][crate::ArgMatches::get_many],
//! their [ordering with other arguments][crate::ArgMatches::indices_of], and [what set
//! them][crate::ArgMatches::value_source]. The Derive API can only report values and not
//! indices of or other data.
//!
//! You can [interop between Derive and Builder APIs][crate::_derive#mixing-builder-and-derive-apis].
//!
//! ### Why is there a default subcommand of help?
//!
//! There is only a default subcommand of `help` when other subcommands have been defined manually. So it's opt-in(ish), being that you only get a `help` subcommand if you're actually using subcommands.
//!
//! Also, if the user defined a `help` subcommand themselves, the auto-generated one wouldn't be added (meaning it's only generated if the user hasn't defined one themselves).
//!

29
vendor/clap/src/_features.rs vendored Normal file
View File

@@ -0,0 +1,29 @@
//! ## Documentation: Feature Flags
//!
//! Available [compile-time feature flags](https://doc.rust-lang.org/cargo/reference/features.html#dependency-features)
//!
//! #### Default Features
//!
//! * `std`: _Not Currently Used._ Placeholder for supporting `no_std` environments in a backwards compatible manner.
//! * `color`: Turns on terminal styling of help and error messages. See
//! [`Command::styles`][crate::Command::styles] to customize this.
//! * `help`: Auto-generate help output
//! * `usage`: Auto-generate usage
//! * `error-context`: Include contextual information for errors (which arg failed, etc)
//! * `suggestions`: Turns on the `Did you mean '--myoption'?` feature for when users make typos.
//!
//! #### Optional features
//!
//! * `deprecated`: Guided experience to prepare for next breaking release (at different stages of development, this may become default)
//! * `derive`: Enables the custom derive (i.e. `#[derive(Parser)]`). Without this you must use one of the other methods of creating a `clap` CLI listed above.
//! * `cargo`: Turns on macros that read values from [`CARGO_*` environment variables](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates).
//! * `env`: Turns on the usage of environment variables during parsing.
//! * `unicode`: Turns on support for unicode characters (including emoji) in arguments and help messages.
//! * ``wrap_help``: Turns on the help text wrapping feature, based on the terminal size.
//! * `string`: Allow runtime generated strings (e.g. with [`Str`][crate::builder::Str]).
//!
//! #### Experimental features
//!
//! **Warning:** These may contain breaking changes between minor releases.
//!
//! * `unstable-v5`: Preview features which will be stable on the v5.0 release

246
vendor/clap/src/_tutorial.rs vendored Normal file
View File

@@ -0,0 +1,246 @@
// Contributing
//
// New example code:
// - Please update the corresponding section in the derive tutorial
// - Building: They must be added to `Cargo.toml` with the appropriate `required-features`.
// - Testing: Ensure there is a markdown file with [trycmd](https://docs.rs/trycmd) syntax
//
// See also the general CONTRIBUTING
//! ## Tutorial for the Builder API
//!
//! *See the side bar for the Table of Contents*
//!
//! ## Quick Start
//!
//! You can create an application with several arguments using usage strings.
//!
//! First, ensure `clap` is available:
//! ```console
//! $ cargo add clap
//! ```
//!
//! Here is a preview of the type of application you can make:
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/01_quick.rs")]
//! ```
//!
#![doc = include_str!("../examples/tutorial_builder/01_quick.md")]
//!
//! See also
//! - [FAQ: When should I use the builder vs derive APIs?][crate::_faq#when-should-i-use-the-builder-vs-derive-apis]
//! - The [cookbook][crate::_cookbook] for more application-focused examples
//!
//! ## Configuring the Parser
//!
//! You use [`Command`][crate::Command] to start building a parser.
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/02_apps.rs")]
//! ```
//!
#![doc = include_str!("../examples/tutorial_builder/02_apps.md")]
//!
//! You can use [`command!()`][crate::command!] to fill these fields in from your `Cargo.toml`
//! file. **This requires the [`cargo` feature flag][crate::_features].**
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/02_crate.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/02_crate.md")]
//!
//! You can use [`Command`][crate::Command] methods to change the application level behavior of
//! clap, like [`Command::next_line_help`].
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/02_app_settings.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/02_app_settings.md")]
//!
//! ## Adding Arguments
//!
//! 1. [Positionals](#positionals)
//! 2. [Options](#options)
//! 3. [Flags](#flags)
//! 4. [Required](#required)
//! 5. [Defaults](#defaults)
//! 6. [Subcommands](#subcommands)
//!
//!
//! ### Positionals
//!
//! By default, an [`Arg`] defines a positional argument:
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_03_positional.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_03_positional.md")]
//!
//! Note that the default [`ArgAction`][crate::ArgAction] is [`Set`][crate::ArgAction::Set]. To
//! accept multiple values, override the [action][Arg::action] with [`Append`][crate::ArgAction::Append]:
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_03_positional_mult.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_03_positional_mult.md")]
//!
//! ### Options
//!
//! You can name your arguments with a flag:
//! - Intent of the value is clearer
//! - Order doesn't matter
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_02_option.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_02_option.md")]
//!
//! Note that the default [`ArgAction`][crate::ArgAction] is [`Set`][crate::ArgAction::Set]. To
//! accept multiple occurrences, override the [action][Arg::action] with [`Append`][crate::ArgAction::Append]:
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_02_option_mult.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_02_option_mult.md")]
//!
//! ### Flags
//!
//! Flags can also be switches that can be on/off:
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_01_flag_bool.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_01_flag_bool.md")]
//!
//! To accept multiple flags, use [`Count`][crate::ArgAction::Count]:
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_01_flag_count.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_01_flag_count.md")]
//!
//! ### Required
//!
//! By default, an [`Arg`] is optional which can be changed with
//! [`required`][crate::Arg::required].
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_06_required.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_06_required.md")]
//!
//! ### Defaults
//!
//! We've previously showed that arguments can be [`required`][crate::Arg::required] or optional.
//! When optional, you work with a `Option` and can `unwrap_or`. Alternatively, you can set
//! [`Arg::default_value`][crate::Arg::default_value].
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_05_default_values.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_05_default_values.md")]
//!
//! ### Subcommands
//!
//! Subcommands are defined as [`Command`][crate::Command]s that get added via
//! [`Command::subcommand`][crate::Command::subcommand]. Each instance of a Subcommand can have its
//! own version, author(s), Args, and even its own subcommands.
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/03_04_subcommands.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/03_04_subcommands.md")]
//!
//! ## Validation
//!
//! 1. [Enumerated values](#enumerated-values)
//! 2. [Validated values](#validated-values)
//! 3. [Argument Relations](#argument-relations)
//! 4. [Custom Validation](#custom-validation)
//!
//! An appropriate default parser/validator will be selected for the field's type. See
//! [`value_parser!`][crate::value_parser!] for more details.
//!
//! ### Enumerated values
//!
//! If you have arguments of specific values you want to test for, you can use the
//! [`PossibleValuesParser`] or [`Arg::value_parser(["val1",
//! ...])`][crate::Arg::value_parser] for short.
//!
//! This allows you to specify the valid values for that argument. If the user does not use one of
//! those specific values, they will receive a graceful exit with error message informing them
//! of the mistake, and what the possible valid values are
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_01_possible.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_01_possible.md")]
//!
//! When enabling the [`derive` feature][crate::_features], you can use
//! [`ValueEnum`][crate::ValueEnum] to take care of the boiler plate for you, giving the same
//! results.
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_01_enum.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_01_enum.md")]
//!
//! ### Validated values
//!
//! More generally, you can validate and parse into any data type with [`Arg::value_parser`].
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_02_parse.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_02_parse.md")]
//!
//! A [custom parser][TypedValueParser] can be used to improve the error messages or provide additional validation:
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_02_validate.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_02_validate.md")]
//!
//! See [`Arg::value_parser`][crate::Arg::value_parser] for more details.
//!
//! ### Argument Relations
//!
//! You can declare dependencies or conflicts between [`Arg`][crate::Arg]s or even
//! [`ArgGroup`][crate::ArgGroup]s.
//!
//! [`ArgGroup`][crate::ArgGroup]s make it easier to declare relations instead of having to list
//! each individually, or when you want a rule to apply "any but not all" arguments.
//!
//! Perhaps the most common use of [`ArgGroup`][crate::ArgGroup]s is to require one and *only* one
//! argument to be present out of a given set. Imagine that you had multiple arguments, and you
//! want one of them to be required, but making all of them required isn't feasible because perhaps
//! they conflict with each other.
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_03_relations.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_03_relations.md")]
//!
//! ### Custom Validation
//!
//! As a last resort, you can create custom errors with the basics of clap's formatting.
//!
//! ```rust
#![doc = include_str!("../examples/tutorial_builder/04_04_custom.rs")]
//! ```
#![doc = include_str!("../examples/tutorial_builder/04_04_custom.md")]
//!
//! ## Testing
//!
//! clap reports most development errors as `debug_assert!`s. Rather than checking every
//! subcommand, you should have a test that calls
//! [`Command::debug_assert`][crate::Command::debug_assert]:
//! ```rust,no_run
#![doc = include_str!("../examples/tutorial_builder/05_01_assert.rs")]
//! ```
//!
//! ## Next Steps
//!
//! - [Cookbook][crate::_cookbook] for application-focused examples
//! - Explore more features in the [API reference][super]
//!
//! For support, see [Discussions](https://github.com/clap-rs/clap/discussions)
#![allow(unused_imports)]
use crate::builder::*;

108
vendor/clap/src/bin/stdio-fixture.rs vendored Normal file
View File

@@ -0,0 +1,108 @@
use clap::{Arg, ArgAction, Command, builder::PossibleValue};
fn main() {
#[allow(unused_mut)]
let mut cmd = Command::new("stdio-fixture")
.version("1.0")
.long_version("1.0 - a2132c")
.term_width(0)
.max_term_width(0)
.arg_required_else_help(true)
.subcommand(Command::new("more"))
.subcommand(
Command::new("test")
.visible_alias("do-stuff")
.long_about("Subcommand with one visible alias"),
)
.subcommand(
Command::new("test_2")
.visible_aliases(["do-other-stuff", "tests"])
.about("several visible aliases")
.long_about("Subcommand with multiple visible aliases"),
)
.subcommand(
Command::new("test_3")
.long_flag("test")
.about("several visible long flag aliases")
.visible_long_flag_aliases(["testing", "testall", "test_all"]),
)
.subcommand(
Command::new("test_4")
.short_flag('t')
.about("several visible short flag aliases")
.visible_short_flag_aliases(['q', 'w']),
)
.subcommand(
Command::new("test_5")
.short_flag('e')
.long_flag("test-hdr")
.about("all kinds of visible aliases")
.visible_aliases(["tests_4k"])
.visible_long_flag_aliases(["thetests", "t4k"])
.visible_short_flag_aliases(['r', 'y']),
)
.arg(
Arg::new("verbose")
.long("verbose")
.help("log")
.action(ArgAction::SetTrue)
.long_help("more log"),
)
.arg(
Arg::new("config")
.action(ArgAction::Set)
.help("Speed configuration")
.short('c')
.long("config")
.value_name("MODE")
.value_parser([
PossibleValue::new("fast"),
PossibleValue::new("slow").help("slower than fast"),
PossibleValue::new("secret speed").hide(true),
])
.default_value("fast"),
)
.arg(
Arg::new("name")
.action(ArgAction::Set)
.help("App name")
.long_help("Set the instance app name")
.value_name("NAME")
.visible_alias("app-name")
.default_value("clap"),
)
.arg(
Arg::new("fruits")
.short('f')
.visible_short_alias('b')
.action(ArgAction::Append)
.value_name("FRUITS")
.help("List of fruits")
.default_values(["apple", "banane", "orange"]),
);
#[cfg(feature = "env")]
{
cmd = cmd.arg(
Arg::new("env_arg")
.help("Read from env var when arg is not present.")
.value_name("ENV")
.env("ENV_ARG"),
);
}
#[cfg(feature = "color")]
{
use clap::builder::styling::{AnsiColor, Styles};
const STYLES: Styles = Styles::styled()
.header(AnsiColor::Green.on_default().bold())
.error(AnsiColor::Red.on_default().bold())
.usage(AnsiColor::Green.on_default().bold().underline())
.literal(AnsiColor::Blue.on_default().bold())
.placeholder(AnsiColor::Cyan.on_default())
.valid(AnsiColor::Green.on_default())
.invalid(AnsiColor::Magenta.on_default().bold())
.context(AnsiColor::Yellow.on_default().dimmed())
.context_value(AnsiColor::Yellow.on_default().italic());
cmd = cmd.styles(STYLES);
}
cmd.get_matches();
}

110
vendor/clap/src/lib.rs vendored Normal file
View File

@@ -0,0 +1,110 @@
// Copyright ⓒ 2015-2016 Kevin B. Knapp and [`clap-rs` contributors](https://github.com/clap-rs/clap/graphs/contributors).
// Licensed under the MIT license
// (see LICENSE or <http://opensource.org/licenses/MIT>) All files in the project carrying such
// notice may not be copied, modified, or distributed except according to those terms.
//! > **Command Line Argument Parser for Rust**
//!
//! Quick Links:
//! - Derive [tutorial][_derive::_tutorial] and [reference][_derive]
//! - Builder [tutorial][_tutorial] and [reference][Command]
//! - [Cookbook][_cookbook]
//! - [CLI Concepts][_concepts]
//! - [FAQ][_faq]
//! - [Discussions](https://github.com/clap-rs/clap/discussions)
//! - [CHANGELOG](https://github.com/clap-rs/clap/blob/v4.6.0/CHANGELOG.md) (includes major version migration
//! guides)
//!
//! ## Aspirations
//!
//! - Out of the box, users get a polished CLI experience
//! - Including common argument behavior, help generation, suggested fixes for users, colored output, [shell completions](https://github.com/clap-rs/clap/tree/master/clap_complete), etc
//! - Flexible enough to port your existing CLI interface
//! - However, we won't necessarily streamline support for each use case
//! - Reasonable parse performance
//! - Resilient maintainership, including
//! - Willing to break compatibility rather than batching up breaking changes in large releases
//! - Leverage feature flags to keep to one active branch
//! - Being under [WG-CLI](https://github.com/rust-cli/team/) to increase the bus factor
//! - We follow semver and will wait about 6-9 months between major breaking changes
//! - We will support the last two minor Rust releases (MSRV, currently 1.74)
//!
//! While these aspirations can be at odds with fast build times and low binary
//! size, we will still strive to keep these reasonable for the flexibility you
//! get. Check out the
//! [argparse-benchmarks](https://github.com/rust-cli/argparse-benchmarks-rs) for
//! CLI parsers optimized for other use cases.
//!
//! ## Example
//!
//! Run
//! ```console
//! $ cargo add clap --features derive
//! ```
//! *(See also [feature flag reference][_features])*
//!
//! Then define your CLI in `main.rs`:
//! ```rust
//! # #[cfg(feature = "derive")] {
#![doc = include_str!("../examples/demo.rs")]
//! # }
//! ```
//!
//! And try it out:
#![doc = include_str!("../examples/demo.md")]
//!
//! See also the derive [tutorial][_derive::_tutorial] and [reference][_derive]
//!
//! ### Related Projects
//!
//! Augment clap:
//! - [wild](https://crates.io/crates/wild) for supporting wildcards (`*`) on Windows like you do Linux
//! - [argfile](https://crates.io/crates/argfile) for loading additional arguments from a file (aka response files)
//! - [shadow-rs](https://crates.io/crates/shadow-rs) for generating `Command::long_version`
//! - [clap_mangen](https://crates.io/crates/clap_mangen) for generating man page source (roff)
//! - [clap_complete](https://crates.io/crates/clap_complete) for shell completion support
//! - [clap-i18n-richformatter](https://crates.io/crates/clap-i18n-richformatter) for i18n support with `clap::error::RichFormatter`
//!
//! CLI Helpers
//! - [clio](https://crates.io/crates/clio) for reading/writing to files specified as arguments
//! - [clap-verbosity-flag](https://crates.io/crates/clap-verbosity-flag)
//! - [clap-cargo](https://crates.io/crates/clap-cargo)
//! - [colorchoice-clap](https://crates.io/crates/colorchoice-clap)
//!
//! Testing
//! - [`trycmd`](https://crates.io/crates/trycmd): Bulk snapshot testing
//! - [`snapbox`](https://crates.io/crates/snapbox): Specialized snapshot testing
//! - [`assert_cmd`](https://crates.io/crates/assert_cmd) and [`assert_fs`](https://crates.io/crates/assert_fs): Customized testing
//!
//! Documentation:
//! - [Command-line Apps for Rust](https://rust-cli.github.io/book/index.html) book
//!
#![doc(html_logo_url = "https://raw.githubusercontent.com/clap-rs/clap/master/assets/clap.png")]
#![cfg_attr(docsrs, feature(doc_cfg))]
#![forbid(unsafe_code)]
#![warn(missing_docs)]
#![warn(clippy::print_stderr)]
#![warn(clippy::print_stdout)]
pub use clap_builder::*;
#[cfg(feature = "derive")]
#[doc(hidden)]
pub use clap_derive::{self, Args, Parser, Subcommand, ValueEnum};
#[cfg(feature = "unstable-doc")]
pub mod _concepts;
#[cfg(feature = "unstable-doc")]
pub mod _cookbook;
#[cfg(feature = "unstable-doc")]
pub mod _derive;
#[cfg(feature = "unstable-doc")]
pub mod _faq;
#[cfg(feature = "unstable-doc")]
pub mod _features;
#[cfg(feature = "unstable-doc")]
pub mod _tutorial;
#[doc = include_str!("../README.md")]
#[cfg(doctest)]
pub struct ReadmeDoctests;