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

behavior change regarding possible_values on derived boolean args in 4.4.14 #5300

Closed
2 tasks done
ahl opened this issue Jan 12, 2024 · 3 comments
Closed
2 tasks done
Labels
C-bug Category: Updating dependencies

Comments

@ahl
Copy link

ahl commented Jan 12, 2024

Please complete the following tasks

Rust Version

rustc 1.75.0 (82e1608df 2023-12-21)

Clap Version

4.4.14

Minimal reproducible code

use clap::{CommandFactory, Parser};

#[derive(Parser)]
pub struct Args {
    #[clap(long)]
    ok: bool,
}

fn main() {
    let values = Args::command()
        .get_arguments()
        .next()
        .expect("no arguments")
        .get_possible_values();
    println!("{:#?}", values);
}

Steps to reproduce the bug with the above code

Use 4.4.13; cargo run:

[]

Use 4.4.14; cargo run:

[
    PossibleValue {
        name: "true",
        help: None,
        aliases: [],
        hide: false,
    },
    PossibleValue {
        name: "false",
        help: None,
        aliases: [],
        hide: false,
    },
]

Actual Behaviour

Behavior change from 4.4.13 to 4.4.14

Expected Behaviour

No behavior change? Unless this was intentional. I didn't see it mentioned in the release notes.

Additional Context

No response

Debug Output

No response

@ahl ahl added the C-bug Category: Updating dependencies label Jan 12, 2024
@epage
Copy link
Member

epage commented Jan 12, 2024

This change of behavior is expected but there is something you can do on your side to address it.

In clap, args have two settings that describe whether a value is accepted or not

  • num_args
  • action

When an argument doesn't take a value, we don't return the possible values.

With 4.4.14, we added support for .action(ArgAction::Set).num_args(0) which introduced a discrepancy, action only describe if an arg might take a value.

To do this, we needed to change out "takes value" tracking which is mostly unnoticeable because we auto-fill in properties when parsing.

The problem is that you are looking at the possible values without the auto-fill of properties. If you call Command::build, the problem goes away.

See

#!/usr/bin/env nargo
---
[dependencies]
clap = { path = "../clap", features = ["derive"] }
---

use clap::{CommandFactory, Parser};

#[derive(Parser)]
pub struct Args {
    #[clap(long)]
    ok: bool,
}

fn main() {
    let mut cmd = Args::command();
    cmd.build();
    let values = cmd
        .get_arguments()
        .next()
        .expect("no arguments")
        .get_possible_values();
    println!("{:#?}", values);
}

@epage
Copy link
Member

epage commented Jan 12, 2024

#2911 covers some of this problem in the API

@ahl
Copy link
Author

ahl commented Jan 12, 2024

This is extremely helpful. Thanks very much. Feel free to close this, or leave it open if there's some work item such as updating the release notes that might be relevant.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Updating dependencies
Projects
None yet
Development

No branches or pull requests

2 participants