Clippy like --allow --deny arguments

[Boshen]

Given clippy like allow / deny arguments https://github.com/rust-lang/rust-clippy#allowingdenying-lints

cargo clippy -- -A clippy::all -W clippy::useless_format -W clippy::...

I'd like to collect this into Vec<(AllowWarnDeny, String)>.

I spent an hour and couldn't figure out a way to achieve this.

[pacak]

I appreciate you making a ticket, it is important for me to know weak points of the documentation.

Let's start simple - you want to parse a single rule that can be one of allow, warn or deny. To represent that in your code you'd use enum Here I used both named variants and tuple variants to show the possibilities, you'd stick to just one.

use bpaf::*;

#[derive(Debug, Clone, Bpaf)]
enum RuleState {
    Allow (
        /// allow the rule
        #[bpaf(short('a'), long("allow"), argument("RULE"))]
        String,
    ),
    Warn {
        /// warn about the rule, but allow it
        #[bpaf(short, long, argument("RULE"))]
        warn: String,
    },
    Deny {
        /// deny the rule
        #[bpaf(short, long, argument("RULE"))]
        deny: String,
    },
}

With that in place you can collect multiple of those rules to a vector with many

...

#[derive(Debug, Clone, Bpaf)]
pub struct Options {
    #[bpaf(external(rule_state), many)]
    rules: Vec<RuleState>
}

Now, if you want to stick to tuples you can do that too:

...

impl RuleState {
    fn to_tuple(self) -> (AllowWarnDeny, String) {
        ...
    }
}

#[derive(Debug, Clone, Bpaf)]
pub struct Options {
    #[bpaf(external(rule_state), map(RuleState::to_tuple), many)]
    rules: Vec<(AllowWarnDeny, String)>
}

I'm assuming you have some enum (Rule) to represent all rules and this enum implements FromStr. You can improve user experience by using this Rule instead of String in the example above. bpaf will validate if rule is valid before execution reaches your code.

[Boshen]

Thank you so much for helping out so quickly!

This was my first attempt:

#[derive(Debug, Clone, Bpaf)]
pub enum LintFilter {
    /// Allow the rule
    #[bpaf(short('a'), long("allow"), argument("RULE"))]
    Allow(String),
    /// Deny the rule
    #[bpaf(short('d'), long("deny"), argument("RULE"))]
    Deny(String),
}

All previous examples with enums looked similar to this expect it was command on the enums, so it felt natural to present OR logic on the enums with argument.

But it gave me the error Unexpected attribute for enum variant annotation (rustc)

This led me to the thought "We can not present OR logic with enum and arguments", so I stopped reaching for similar solutions again where enums appear.

Then I posted this help and kept going for 3 hours trying to get any to work because it vaguely convey the idea of OR.

---

PR and result

• https://github.com/web-infra-dev/oxc/pull/758/files

(I can crate issues for the misalignments and missing paragraphs on group_help).

[pacak]

This led me to the thought "We can not present OR logic with enum and arguments", so I stopped reaching for similar solutions again where enums appear.

Hmm.... I see, I guess I should finish implementing this #146 or improve error message from derive crate and work on improving derive macro documentation.

Either way this is a very useful feedback

(I can crate issues for the misalignments and missing paragraphs on group_help).

Interesting. 2 spaces align for "To allow or deny ..." is somewhat expected, but it should be under "Available options:" somehow. But then again, looking at my own cargo-show-asm I see groups like this...

Postprocessing options:
        --rust                Print interleaved Rust code
        --color               Enable color highlighting
        --no-color            Disable color highlighting
        --full-name           Include full demangled name instead of just prefix
        --keep-labels         Keep all the original labels
    -v, --verbose             more verbose output, can be specified multiple times
        --simplify            Try to strip some of the non-assembly instruction information

Pick output format:
        --intel               Show assembly using Intel style
        --att                 Show assembly using AT&T style
        --llvm                Show llvm-ir
        --llvm-input          Show llvm-ir before any LLVM passes
        --mir                 Show MIR
        --wasm                Show WASM, needs wasm32-unknown-unknown target installed
        --mca-intel           Show llvm-mca analysis, Intel style asm
        --mca-att             Show llvm-mca analysis, AT&T style asm

So yea, please make a ticket - I'll look into it.