2018-07-02 17:41:01 +00:00
|
|
|
// Copyright 2018 Guillaume Pinot (@TeXitoi) <texitoi@texitoi.eu>,
|
|
|
|
// Kevin Knapp (@kbknapp) <kbknapp@gmail.com>, and
|
2022-01-04 20:10:35 +00:00
|
|
|
// Ana Hobden (@hoverbear) <operator@hoverbear.org>
|
2018-02-04 18:27:45 +00:00
|
|
|
//
|
2018-02-25 10:22:24 +00:00
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
2018-07-02 17:41:01 +00:00
|
|
|
//
|
|
|
|
// This work was derived from Structopt (https://github.com/TeXitoi/structopt)
|
|
|
|
// commit#ea76fa1b1b273e65e3b0b1046643715b49bec51f which is licensed under the
|
|
|
|
// MIT/Apache 2.0 license.
|
2018-02-04 18:27:45 +00:00
|
|
|
|
2020-03-05 10:34:29 +00:00
|
|
|
#![allow(clippy::option_option)]
|
|
|
|
|
2021-11-30 15:36:53 +00:00
|
|
|
use crate::utils;
|
2021-08-01 21:50:31 +00:00
|
|
|
|
2021-10-11 19:48:13 +00:00
|
|
|
use clap::{Parser, Subcommand};
|
2018-02-04 18:27:45 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn required_option() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2018-02-04 18:27:45 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long)]
|
2018-02-04 18:27:45 +00:00
|
|
|
arg: i32,
|
|
|
|
}
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a42"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "42"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "--arg", "42"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2022-06-01 15:31:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "--arg", "24", "--arg", "42"]).unwrap()
|
2022-06-01 15:31:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert!(Opt::try_parse_from(["test"]).is_err());
|
2018-02-04 18:27:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn option_with_default() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2018-02-04 18:27:45 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, default_value = "42")]
|
2018-02-04 18:27:45 +00:00
|
|
|
arg: i32,
|
|
|
|
}
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 24 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a24"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2022-06-01 15:31:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
2022-06-01 15:31:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: 42 }, Opt::try_parse_from(["test"]).unwrap());
|
2018-02-04 18:27:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn option_with_raw_default() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2018-02-04 18:27:45 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, default_value = "42")]
|
2018-02-04 18:27:45 +00:00
|
|
|
arg: i32,
|
|
|
|
}
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 24 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a24"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2022-06-01 15:31:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
2022-06-01 15:31:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: 42 }, Opt::try_parse_from(["test"]).unwrap());
|
2018-02-04 18:27:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn option_from_str() {
|
2022-06-06 18:20:50 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
2021-11-04 15:15:04 +00:00
|
|
|
struct A;
|
|
|
|
|
2022-06-06 18:20:50 +00:00
|
|
|
impl std::str::FromStr for A {
|
|
|
|
type Err = std::convert::Infallible;
|
|
|
|
|
|
|
|
fn from_str(_: &str) -> Result<A, Self::Err> {
|
|
|
|
Ok(A)
|
2021-11-04 15:15:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Parser, PartialEq)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2018-02-04 18:27:45 +00:00
|
|
|
struct Opt {
|
2021-11-04 15:15:04 +00:00
|
|
|
a: Option<A>,
|
2018-02-04 18:27:45 +00:00
|
|
|
}
|
2021-11-04 15:15:04 +00:00
|
|
|
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { a: None }, Opt::try_parse_from(["test"]).unwrap());
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt { a: Some(A) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "foo"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2021-11-04 15:15:04 +00:00
|
|
|
}
|
|
|
|
|
2022-05-13 21:04:03 +00:00
|
|
|
#[test]
|
|
|
|
fn vec_from_str() {
|
2022-06-06 18:20:50 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
2022-05-13 21:04:03 +00:00
|
|
|
struct A;
|
|
|
|
|
2022-06-06 18:20:50 +00:00
|
|
|
impl std::str::FromStr for A {
|
|
|
|
type Err = std::convert::Infallible;
|
|
|
|
|
|
|
|
fn from_str(_: &str) -> Result<A, Self::Err> {
|
|
|
|
Ok(A)
|
2022-05-13 21:04:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Parser, PartialEq)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2022-05-13 21:04:03 +00:00
|
|
|
struct Opt {
|
|
|
|
a: Vec<A>,
|
|
|
|
}
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
Opt { a: Vec::new() },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test"]).unwrap()
|
2022-05-13 21:04:03 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt { a: vec![A] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "foo"]).unwrap()
|
2022-05-13 21:04:03 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn option_vec_from_str() {
|
2022-06-06 18:20:50 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
2022-05-13 21:04:03 +00:00
|
|
|
struct A;
|
|
|
|
|
2022-06-06 18:20:50 +00:00
|
|
|
impl std::str::FromStr for A {
|
|
|
|
type Err = std::convert::Infallible;
|
|
|
|
|
|
|
|
fn from_str(_: &str) -> Result<A, Self::Err> {
|
|
|
|
Ok(A)
|
2022-05-13 21:04:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Parser, PartialEq)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2022-05-13 21:04:03 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2022-05-13 21:04:03 +00:00
|
|
|
a: Option<Vec<A>>,
|
|
|
|
}
|
|
|
|
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { a: None }, Opt::try_parse_from(["test"]).unwrap());
|
2022-05-13 21:04:03 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { a: Some(vec![A]) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "foo"]).unwrap()
|
2022-05-13 21:04:03 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2021-11-04 15:15:04 +00:00
|
|
|
#[test]
|
|
|
|
fn option_type_is_optional() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2021-11-04 15:15:04 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: Option<i32>,
|
|
|
|
}
|
2018-05-21 14:54:22 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt { arg: Some(42) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a42"]).unwrap()
|
2018-05-21 14:54:22 +00:00
|
|
|
);
|
2022-06-01 15:31:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: Some(42) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
2022-06-01 15:31:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: None }, Opt::try_parse_from(["test"]).unwrap());
|
2018-02-04 18:27:45 +00:00
|
|
|
}
|
2018-02-12 22:46:15 +00:00
|
|
|
|
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn required_with_option_type() {
|
|
|
|
#[derive(Debug, PartialEq, Eq, Parser)]
|
2022-09-02 20:37:23 +00:00
|
|
|
#[command(subcommand_negates_reqs = true)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2018-02-12 22:46:15 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(required = true)]
|
2021-11-04 15:15:04 +00:00
|
|
|
req_str: Option<String>,
|
|
|
|
|
2022-09-02 20:37:23 +00:00
|
|
|
#[command(subcommand)]
|
2021-11-04 15:15:04 +00:00
|
|
|
cmd: Option<SubCommands>,
|
2018-02-12 22:46:15 +00:00
|
|
|
}
|
2021-11-04 15:15:04 +00:00
|
|
|
|
|
|
|
#[derive(Debug, PartialEq, Eq, Subcommand)]
|
|
|
|
enum SubCommands {
|
|
|
|
ExSub {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long, action = clap::ArgAction::Count)]
|
2022-06-09 16:09:36 +00:00
|
|
|
verbose: u8,
|
2021-11-04 15:15:04 +00:00
|
|
|
},
|
|
|
|
}
|
|
|
|
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt {
|
|
|
|
req_str: Some(("arg").into()),
|
|
|
|
cmd: None,
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "arg"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2021-11-04 15:15:04 +00:00
|
|
|
|
2018-05-21 14:54:22 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt {
|
|
|
|
req_str: None,
|
|
|
|
cmd: Some(SubCommands::ExSub { verbose: 1 }),
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "ex-sub", "-v"]).unwrap()
|
2018-05-21 14:54:22 +00:00
|
|
|
);
|
2021-11-04 15:15:04 +00:00
|
|
|
|
2022-11-24 13:54:25 +00:00
|
|
|
assert!(Opt::try_parse_from(["test"]).is_err());
|
2018-02-12 22:46:15 +00:00
|
|
|
}
|
2020-01-07 10:17:23 +00:00
|
|
|
|
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn ignore_qualified_option_type() {
|
2022-06-06 18:20:50 +00:00
|
|
|
fn parser(s: &str) -> Result<Option<String>, std::convert::Infallible> {
|
|
|
|
Ok(Some(s.to_string()))
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
|
2021-11-04 15:15:04 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2020-01-07 10:17:23 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(value_parser = parser)]
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: ::std::option::Option<String>,
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt {
|
|
|
|
arg: Some("success".into())
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "success"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn option_option_type_is_optional_value() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2020-01-07 10:17:23 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2020-01-07 10:17:23 +00:00
|
|
|
#[allow(clippy::option_option)]
|
|
|
|
arg: Option<Option<i32>>,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(Some(42))
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a42"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: Some(None) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
2022-06-01 15:31:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(Some(42))
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
2022-06-01 15:31:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: None }, Opt::try_parse_from(["test"]).unwrap());
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
|
2021-08-01 21:50:31 +00:00
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn option_option_type_help() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2021-08-01 21:50:31 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(long, value_name = "val")]
|
2021-08-01 21:50:31 +00:00
|
|
|
arg: Option<Option<i32>>,
|
|
|
|
}
|
2021-11-30 15:36:53 +00:00
|
|
|
let help = utils::get_help::<Opt>();
|
2022-07-29 14:40:24 +00:00
|
|
|
assert!(help.contains("--arg [<val>]"));
|
|
|
|
assert!(!help.contains("--arg [<val>...]"));
|
2021-08-01 21:50:31 +00:00
|
|
|
}
|
|
|
|
|
2020-01-07 10:17:23 +00:00
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn two_option_option_types() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2020-01-07 10:17:23 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2020-01-07 10:17:23 +00:00
|
|
|
arg: Option<Option<i32>>,
|
|
|
|
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(long)]
|
2020-01-07 10:17:23 +00:00
|
|
|
field: Option<Option<String>>,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(Some(42)),
|
|
|
|
field: Some(Some("f".into()))
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a42", "--field", "f"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(Some(42)),
|
|
|
|
field: Some(None)
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a42", "--field"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(None),
|
|
|
|
field: Some(None)
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "--field"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(None),
|
|
|
|
field: Some(Some("f".into()))
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "--field", "f"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: None,
|
|
|
|
field: Some(None)
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "--field"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: None,
|
|
|
|
field: None
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
fn vec_type_is_multiple_occurrences() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2020-01-07 10:17:23 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long)]
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: Vec<i32>,
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt { arg: vec![24] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a24"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: vec![] }, Opt::try_parse_from(["test"]).unwrap());
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: vec![24, 42] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn vec_type_with_required() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long, required = true)]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
arg: Vec<i32>,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: vec![24] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a24"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert!(Opt::try_parse_from(["test"]).is_err());
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: vec![24, 42] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "-a", "42"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn vec_type_with_multiple_values_only() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long, num_args(1..))]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
arg: Vec<i32>,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: vec![24] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a24"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: vec![] }, Opt::try_parse_from(["test"]).unwrap());
|
2020-01-07 10:17:23 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt { arg: vec![24, 42] },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "24", "42"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
2021-11-04 15:15:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn ignore_qualified_vec_type() {
|
2022-06-06 18:20:50 +00:00
|
|
|
fn parser(s: &str) -> Result<Vec<String>, std::convert::Infallible> {
|
|
|
|
Ok(vec![s.to_string()])
|
2021-11-04 15:15:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2021-11-04 15:15:04 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(value_parser = parser)]
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: ::std::vec::Vec<String>,
|
|
|
|
}
|
2020-01-07 10:17:23 +00:00
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: vec!["success".into()]
|
2020-01-07 10:17:23 +00:00
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "success"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
2021-11-04 15:15:04 +00:00
|
|
|
}
|
2020-01-07 10:17:23 +00:00
|
|
|
|
2021-11-04 15:15:04 +00:00
|
|
|
#[test]
|
|
|
|
fn option_vec_type() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2021-11-04 15:15:04 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2021-11-04 15:15:04 +00:00
|
|
|
arg: Option<Vec<i32>>,
|
|
|
|
}
|
2020-01-07 10:17:23 +00:00
|
|
|
assert_eq!(
|
2021-11-04 15:15:04 +00:00
|
|
|
Opt { arg: Some(vec![1]) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(vec![1, 2])
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1", "-a", "2"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
|
|
|
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: None }, Opt::try_parse_from(["test"]).unwrap());
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn option_vec_type_structopt_behavior() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short, long, num_args(0..))]
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
arg: Option<Vec<i32>>,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: Some(vec![1]) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1"]).unwrap()
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
);
|
|
|
|
|
2020-01-07 10:17:23 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(vec![1, 2])
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1", "2"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: Some(vec![]) },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2020-01-07 10:17:23 +00:00
|
|
|
|
2022-11-24 13:54:25 +00:00
|
|
|
assert_eq!(Opt { arg: None }, Opt::try_parse_from(["test"]).unwrap());
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
2021-11-04 15:15:04 +00:00
|
|
|
fn two_option_vec_types() {
|
2021-07-13 17:50:55 +00:00
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2020-01-07 10:17:23 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2020-01-07 10:17:23 +00:00
|
|
|
arg: Option<Vec<i32>>,
|
|
|
|
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(short)]
|
2020-01-07 10:17:23 +00:00
|
|
|
b: Option<Vec<i32>>,
|
|
|
|
}
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(vec![1]),
|
fix(derive): Define multiple policy for Special Types
Before:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple values, optional
- `Option<Vec<_>>`: multiple values, min values of 0, optional
After:
- `bool`: a flag
- `Option<_>`: not required
- `Option<Option<_>>` is not required and when it is present, the value
is not required
- `Vec<_>`: multiple occurrences, optional
- optional: `Vec` implies 0 or more, so should not imply required
- `Option<Vec<_>>`: multiple occurrences, optional
- optional: Use over `Vec` to detect when no option being present when
using multiple values
Motivations:
My priorities were:
1. Are we getting in the users way?
2. Does the API make sense?
3. Does the API encourage best practices?
I was originally concerned about the lack of composability with
`Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`).
It prescribes special meaning to each type depending on where it shows
up, rather than providing a single meaning for a type generally. You
then can't do things like have `Option<_>` mean "required argument with
optional value" without hand constructing it. However, in practice the
outer type correlates with the argument occurrence and the inner type
with the value. It is rare to want the value behavior without also the
occurrence behavior. So I figure it is probably fine as long as people
can set the flags to manually get the behavior they want.
`Vec<_>` implies multiple occurrences, rather than multiple values.
Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was
getting `Arg::multiple_occurrences` only. `Arg::multiple_values`,
without any bounds or delimiter requirement, can lead to a confusing
user experience and isn't a good default for these. On top of that, if
someone does have an unbounded or a delimiter multiple values, they are
probably also using multiple occurrences.
`Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to
the meaning of the rust type. At least for me, I also rarely need a
required with multiple occurrences argument but more often need optional
with multiple occurrences.
`Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question
of why have it. Some users might prefer the type. Otherwise, this is
so users can detect whether the argument is present or not when using
`min_values(0)`. Rather than defining an entire policy around this and
having users customize it, or setting `min_values(0)` without the rest
of a default policy, this gives people a blank slate to work from.
Another design option would have been to not infer any special-type
settings if someone sets a handful of settings manually, which would
have avoided the confusion in Issue clap-rs/clap 2599 but I see that
being confusing (for someone who knows the default, they will be
expecting it to be additive; which flags disable inferred settings?) and
brittle (as flags are added or changed, how do we ensure we keep this
up?).
Tests were added to ensure we support people customizing the behavior to
match their needs.
This is not solving:
- `Vec<Vec<_>>`, see clap-rs/clap 2924
- `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717
- `Vec<Option<_>>` and many other potential combinations
Fixes clap-rs/clap 1772
Fixes clap-rs/clap 2599
See also clap-rs/clap 2195
2021-10-27 18:33:36 +00:00
|
|
|
b: None,
|
2020-01-07 10:17:23 +00:00
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(vec![1]),
|
2021-11-04 15:15:04 +00:00
|
|
|
b: Some(vec![1])
|
2020-01-07 10:17:23 +00:00
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1", "-b", "1"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
Opt {
|
|
|
|
arg: Some(vec![1, 2]),
|
|
|
|
b: Some(vec![1, 2])
|
|
|
|
},
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "-a", "1", "-a", "2", "-b", "1", "-b", "2"]).unwrap()
|
2020-01-07 10:17:23 +00:00
|
|
|
);
|
|
|
|
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: None, b: None },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test"]).unwrap()
|
test(derive): Provide better error info
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
2021-10-30 14:55:50 +00:00
|
|
|
);
|
2020-01-07 10:17:23 +00:00
|
|
|
}
|
2022-05-20 17:43:11 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn explicit_value_parser() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2022-05-20 17:43:11 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(long, value_parser = clap::value_parser!(i32))]
|
2022-05-20 17:43:11 +00:00
|
|
|
arg: i32,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "--arg", "42"]).unwrap()
|
2022-05-20 17:43:11 +00:00
|
|
|
);
|
|
|
|
}
|
2022-05-21 00:25:20 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn implicit_value_parser() {
|
|
|
|
#[derive(Parser, PartialEq, Debug)]
|
2022-09-23 20:18:14 +00:00
|
|
|
#[command(args_override_self = true)]
|
2022-05-21 00:25:20 +00:00
|
|
|
struct Opt {
|
2022-09-02 20:37:23 +00:00
|
|
|
#[arg(long)]
|
2022-05-21 00:25:20 +00:00
|
|
|
arg: i32,
|
|
|
|
}
|
|
|
|
assert_eq!(
|
|
|
|
Opt { arg: 42 },
|
2022-11-24 13:54:25 +00:00
|
|
|
Opt::try_parse_from(["test", "--arg", "42"]).unwrap()
|
2022-05-21 00:25:20 +00:00
|
|
|
);
|
|
|
|
}
|