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

Cannot use non-literal expressions for name attribute #5407

Closed
2 tasks done
mwu-tow opened this issue Mar 20, 2024 · 1 comment · Fixed by #5425 or enso-org/enso#9595
Closed
2 tasks done

Cannot use non-literal expressions for name attribute #5407

mwu-tow opened this issue Mar 20, 2024 · 1 comment · Fixed by #5425 or enso-org/enso#9595
Labels
C-bug Category: Updating dependencies

Comments

@mwu-tow
Copy link

mwu-tow commented Mar 20, 2024

Please complete the following tasks

Rust Version

rustc 1.76.0 (07dca489a 2024-02-04)

Clap Version

4.5.3

Minimal reproducible code

use clap::Parser;

pub trait HasName {
    const NAME: &'static str;
}

pub struct Foo;

impl HasName for Foo {
    const NAME: &'static str = "foo";
}

/// Simple program to greet a person
#[derive(Parser, Debug)]
struct Args<T: HasName> {
    /// Name of the person to greet
    #[clap(name = T::NAME, short, long)]
    name: String,

    #[clap(skip)]
    phantom: std::marker::PhantomData<T>,
}

fn main() {
    Args::<Foo>::parse();
}

Steps to reproduce the bug with the above code

cargo build

Actual Behaviour

Build error:

error: expected a literal
  --> src\main.rs:17:19
   |
17 |     #[clap(name = T::NAME, short, long)]
   |                   ^^^^^^^
   |
   = note: only literals (like `"foo"`, `-42` and `3.14`) can be passed to `concat!()`

Expected Behaviour

This code worked in clap 3.2.25 and was not documented as a change, so I think it still should work.

Also, the documentation says that the name attribute argument is an expression, so I would expect it to work. Especially since there is no restriction on the Command::name API. I don't think there are similar restrictions on other attributes.

Additional Context

This blocks me from migrating to clap v4. I relied on this pattern to reuse the same structure definition, while avoiding the name collisions.

Debug Output

No response

@mwu-tow mwu-tow added the C-bug Category: Updating dependencies label Mar 20, 2024
mergify bot pushed a commit to enso-org/enso that referenced this issue Mar 24, 2024
This PR updates the Rust toolchain to recent nightly.

Most of the changes are related to fixing newly added warnings and adjusting the feature flags. Also the formatter changed its behavior slightly, causing some whitespace changes.

Other points:
* Changed debug level of the `buildscript` profile to `lint-tables-only` — this should improve the build times and space usage somewhat.
* Moved lint configuration to the worksppace `Cargo.toml` definition. Adjusted the formatter appropriately.
* Removed auto-generated IntelliJ run configurations, as they are not useful anymore.
* Added a few trivial stdlib nightly functions that were removed to our codebase.
* Bumped many dependencies but still not all:
* `clap` bump encountered clap-rs/clap#5407 — for now the warnings were silenced by the lint config.
* `octocrab` — our forked diverged to far with the original, needs more refactoring.
* `derivative` — is unmaintained and has no updated version, despite introducing warnings in the generated code. There is no direct replacement.
@epage
Copy link
Member

epage commented Mar 25, 2024

This was broken in #4947. Looking to see if we can better detect when to use one or the other.

epage added a commit to epage/clap that referenced this issue Mar 25, 2024
mergify bot pushed a commit to enso-org/enso that referenced this issue Apr 3, 2024
Now that the clap has fixed [issue](clap-rs/clap#5407) that blocked us, we can bump it across all our crates.

Fixes #5168.
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

Successfully merging a pull request may close this issue.

2 participants