"Could not downcast" from ArgAction::Count

[ssokolow]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

rustc 1.64.0 (a55dd71d5 2022-09-19)

Clap Version

3.2.22 and 4.0.18, though output is from 3.2.22

Minimal reproducible code

use clap::Parser;

#[derive(Parser)]
pub struct CliOpts {
    #[clap(short, action = clap::ArgAction::Count)]
    pub verbose: usize,
}

fn main() -> () {
    let _ = CliOpts::parse();
}

...with clap = { version = "3", features = ["derive"] }

Steps to reproduce the bug with the above code

cargo flamegraph -- -vvv

Actual Behaviour

thread 'main' panicked at 'Mismatch between definition and access of `[hash: 1EC9D3D5DB2284A6]`. Could not downcast to TypeId { t: 13358953601680865708 }, need to downcast to TypeId { t: 13834754221672687376 }
', /home/ssokolow/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/clap-3.2.22/src/parser/parser.rs:1279:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.062 MB perf.data (7 samples) ]
failed to sample program

Expected Behaviour

[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.117 MB perf.data (7 samples) ]
writing flamegraph to "flamegraph.svg"

(Or an error that's not obviously clap's version of an ICE if that's not the correct way to do what I'm aiming for.)

Additional Context

Testing was with flamegraph v0.6.2 (the newest cargo installable version at the moment I'm writing this), in case that proves relevant to reproduction.

While I've confirmed this is still a problem on clap 4.x, I specifically care about 3.x, because I've been using @dependabot ignore this minor version pending the return of proper coloured output.

I find monochromatic --help output ugly and "colored" output using intensity and underline to be worse and I'm waiting for support for colored output to return. (The NO_COLOR environment variable exists for people who don't want color, as does the terminal's control panel to redefine the base 16-color palette if they have trouble with color contrast and readability.)

(If a security vulnerability pops up, I guess I'll have to publish a little crate to construct a help_template for clap 4.x by querying terminfo and the NO_COLOR environment variable and then hard-coding the escape codes for the colors from clap 3.x... assuming that the help_template syntax is versatile enough to reproduce it. I didn't actually check that. If it's not, maybe I'll publish a patched fork of clap 4.x to crates.io for them to depend on so I don't have to maintain tons of different vendored copies as these projects start to get published.)

Debug Output

[      clap::builder::command]  Command::_do_parse
[      clap::builder::command]  Command::_build: name="clap_reproducer"
[      clap::builder::command]  Command::_propagate:clap_reproducer
[      clap::builder::command]  Command::_check_help_and_version: clap_reproducer
[      clap::builder::command]  Command::_check_help_and_version: Removing generated version
[      clap::builder::command]  Command::_propagate_global_args:clap_reproducer
[      clap::builder::command]  Command::_derive_display_order:clap_reproducer
[        clap::parser::parser]  Parser::get_matches_with
[        clap::parser::parser]  Parser::get_matches_with: Begin parsing 'RawOsStr("-vvv")' ([45, 118, 118, 118])
[        clap::parser::parser]  Parser::possible_subcommand: arg=Ok("-vvv")
[        clap::parser::parser]  Parser::get_matches_with: sc=None
[        clap::parser::parser]  Parser::parse_short_arg: short_arg=ShortFlags { inner: RawOsStr("vvv"), utf8_prefix: CharIndices { front_offset: 0, iter: Chars(['v', 'v', 'v']) }, invalid_suffix: None }
[        clap::parser::parser]  Parser::parse_short_arg:iter:v
[        clap::parser::parser]  Parser::parse_short_arg:iter:v: Found valid opt or flag
[        clap::parser::parser]  Parser::react action=Count, identifier=Some(Short), source=CommandLine
[        clap::parser::parser]  Parser::remove_overrides: id=[hash: 1EC9D3D5DB2284A6]
[   clap::parser::arg_matcher]  ArgMatcher::start_custom_arg: id=[hash: 1EC9D3D5DB2284A6], source=CommandLine
[      clap::builder::command]  Command::groups_for_arg: id=[hash: 1EC9D3D5DB2284A6]
[        clap::parser::parser]  Parser::push_arg_values: ["1"]
[        clap::parser::parser]  Parser::add_single_val_to_arg: cur_idx:=1
[      clap::builder::command]  Command::groups_for_arg: id=[hash: 1EC9D3D5DB2284A6]
[        clap::parser::parser]  Parser::parse_short_arg:iter:v
[        clap::parser::parser]  Parser::parse_short_arg:iter:v: Found valid opt or flag
[        clap::parser::parser]  Parser::react action=Count, identifier=Some(Short), source=CommandLine
thread 'main' panicked at 'Mismatch between definition and access of `[hash: 1EC9D3D5DB2284A6]`. Could not downcast to TypeId { t: 13358953601680865708 }, need to downcast to TypeId { t: 13834754221672687376 }
', /home/ssokolow/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/clap-3.2.22/src/parser/parser.rs:1279:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.117 MB perf.data (7 samples) ]
failed to sample program

[slonik-az]

Confirming the bug in the case of clap-4.0.18. The code above does not run at all (never mind flamegraph).

Trying to run it with cargo run panics:

Running `target/debug/examples/flag_count_03`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `u8`,
 right: `usize`: Argument `verbose`'s selected action Count contradicts `value_parser` (ValueParser::other(usize))',
/Users/____/.cargo/registry/src/gitpro.ttaallkk.top-1ecc6299db9ec823/clap-4.0.18/src/builder/debug_asserts.rs:708:9

[ssokolow]

The code above does not run at all (never mind flamegraph).

Maybe I got confused but I remember being very puzzled when it was working for me without cargo flamegraph under 3.2.22. That's why it made it into my set of reproduction instructions.

[slonik-az]

@ssokolow : Could you please change the title of this issue and remove flamegraph from it, for the issue you are reporint is broader than that.

[epage]

(If a security vulnerability pops up, I guess I'll have to publish a little crate to construct a help_template for clap 4.x by querying terminfo and the NO_COLOR environment variable and then hard-coding the escape codes for the colors from clap 3.x... assuming that the help_template syntax is versatile enough to reproduce it. I didn't actually check that. If it's not, maybe I'll publish a patched fork of clap 4.x to crates.io for them to depend on so I don't have to maintain tons of different vendored copies as these projects start to get published.)

Right now, v3 is in maintenance mode and will receive security updates. Even v2 is deprecated, but not obsolete, and we'll still try to resolve showstoppers if they come up.

[epage]

The error message is better under debug builds than release builds.

This error is expected behavior and I would be more surprised by this working than not. ArgAction::Count has only worked with u8's. The old parse(from_occurrences) did support alternative data types. The fix is to either change the data type to u8 or to use parse(from_occurrences) though that will be unavailable in v4. #3912 is one potential way of allowing alternative data types.

As this error is expected, I'm going to go ahead and close this. If there is something I was missing in closing this, let us know!.

[ssokolow]

I thought that might be the case. Could I reopen and rebadge this to be about how fish-to-the-face-ishly surprising and frustratingly confusing it is for a Rust library to giving me an error message I'd expect out of urwid? ...especially when the error message doesn't say "Try again with a debug build, man."

(Urwid is kind of infamous for how it leans on Python's duck-typing in the worst possible way and, if you don't get the declarative UI definitons exactly in line with the schema it expects, your program dies with an AttributeError or TypeError or ValueError two dozen layers deep with a traceback that tells you nothing about what you did wrong.)

[ssokolow]

Actually, now that I think about it, I wonder if the debug/release difference is why, with 3.x, I remember getting a successful run with cargo run -- -vvv and that error with cargo flamegraph -- -vvv.