Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ArgAction::Count type error not caught at compile time #3864

Open
2 tasks done
cyqsimon opened this issue Jun 23, 2022 · 3 comments
Open
2 tasks done

ArgAction::Count type error not caught at compile time #3864

cyqsimon opened this issue Jun 23, 2022 · 3 comments
Labels
A-derive Area: #[derive]` macro API C-bug Category: Updating dependencies E-help-wanted Call for participation: Help is requested to fix this issue. E-medium Call for participation: Experience needed to fix: Medium / intermediate

Comments

@cyqsimon
Copy link

cyqsimon commented Jun 23, 2022

Please complete the following tasks

Rust Version

rustc 1.61.0 (fe5b13d68 2022-05-18)

Clap Version

v3.2.6

Minimal reproducible code

use clap::{ArgAction, Parser};

#[derive(Debug, Clone, Parser)]
pub struct CliArgs {
    #[clap(short = 'v', action = ArgAction::Count)]
    pub verbose: i32,
}
fn main() {
    let _args = CliArgs::parse();
    println!("Hello, world!");
}

Steps to reproduce the bug with the above code

  • Run cargo build and observe that the program builds.
  • Run cargo run and observe that the program panics at runtime due to a type error.

Actual Behaviour

Type error causes a panic at runtime.

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `u8`,
 right: `i32`: Argument `verbose`'s selected action Count contradicts `value_parser` (ValueParser::other(i32))'

Expected Behaviour

Type error should be caught at compile time.

Alternatively, allow upcasting the u8 into user`s preferred type automatically.

@cyqsimon cyqsimon added the C-bug Category: Updating dependencies label Jun 23, 2022
@epage epage added A-derive Area: #[derive]` macro API S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing E-easy Call for participation: Experience needed to fix: Easy / not much and removed S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Jun 28, 2022
@epage
Copy link
Member

epage commented Jun 28, 2022

Thinking through this and the problems we normally have in moving an error to compile time, I think this is one case where we skip most of those.

@epage epage added E-medium Call for participation: Experience needed to fix: Medium / intermediate E-help-wanted Call for participation: Help is requested to fix this issue. and removed E-easy Call for participation: Experience needed to fix: Easy / not much labels Jun 28, 2022
@slonik-az
Copy link

slonik-az commented Oct 24, 2022

The better solution is to automatically downcast to user provided type.
Currently, one cannot even downcast u8 -> usize, see #4417 and #3912.

@tgross35
Copy link
Contributor

tgross35 commented Jan 7, 2023

I think this is also an issue in the example on the args trait page. Currently it has:

#[derive(clap::Parser)]
struct Args {
   #[command(flatten)]
   logging: LogArgs,
}

#[derive(clap::Args)]
struct LogArgs {
   #[arg(long, short = 'v', action = clap::ArgAction::Count)]
   verbose: i8,
}

And I had something based on this that didn't work until I changed i8 to u8

Edit: submitted #4610 to fix just this example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-derive Area: #[derive]` macro API C-bug Category: Updating dependencies E-help-wanted Call for participation: Help is requested to fix this issue. E-medium Call for participation: Experience needed to fix: Medium / intermediate
Projects
None yet
Development

No branches or pull requests

4 participants