Arg::to_string panics

[crowlKats]

Please complete the following tasks

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

Rust Version

1.79.0

Clap Version

4.5.13

Minimal reproducible code

fn main() {
    let cmd = clap::Command::new("cargo")
      .bin_name("cargo")
      .arg(clap::Arg::new("manifest-path").long("manifest-path"));

    dbg!(cmd.get_arguments().next().unwrap().to_string());
}

Steps to reproduce the bug with the above code

cargo run

Actual Behaviour

its panicking with
thread 'main' panicked at /Users/crowlkats/.cargo/registry/src/index.crates.io-6f17d22bba15001f/clap_builder-4.5.13/src/builder/arg.rs:4001:29
which is

clap/clap_builder/src/builder/arg.rs

Line 4024 in edcaf8f

self.get_num_args().expect(INTERNAL_ERROR_MSG).min_values()

Expected Behaviour

shouldn't panic

Additional Context

Am trying to get the arg usage representation to do a basic JSON output.

Debug Output

No response

[epage]

You need to cmd.build() first.

The next question is if our panic message should call that out. I'm unsure. There are a lot of corner cases and am unsure if we should go for "catastrophic failure" or "you didn't do one specific thing" (when you might have and instead something else went wrong).

[crowlKats]

You need to cmd.build() first.

Ah, that makes sense.

The next question is if our panic message should call that out. I'm unsure. There are a lot of corner cases and am unsure if we should go for "catastrophic failure" or "you didn't do one specific thing" (when you might have and instead something else went wrong).

I tend to be in favour of more documentation, especially if its a behaviour that is here to stay indefinitively and has a reason, but I do understand your point, especially if such cases are common, so not sure either which would be better.