Re: [PATCH] rust: cpufreq: fix clippy::double_parens warning in Policy doctest
From: Gary Guo
Date: Thu Mar 05 2026 - 07:37:25 EST
On Wed Mar 4, 2026 at 9:13 PM GMT, John Hubbard wrote:
> On 3/4/26 12:39 PM, Gary Guo wrote:
> ...
>> Actually `Delimiter::None` isn't fully fixed [1], so perhaps let's done use this
>> approach.
>>
>> Injecting a `#[allow(clippy::double_parens)]` would probably a better approach
>> today.
>>
>
> OK, so that gets us here:
>
> commit 924f411d6cd0cc4d702f197566f5e701915d5760 (HEAD -> fix-clippy-double-parens-v2)
> Author: John Hubbard <jhubbard@xxxxxxxxxx>
> Date: Wed Mar 4 13:07:43 2026 -0800
>
> scripts/rustdoc_test_gen.rs: suppress clippy::double_parens in doctests
>
> The fmt! proc macro wraps each format argument like &(arg). Writing a
> tuple argument such as (a, b) produces &((a, b)) after expansion.
> Clippy flags that as double parens, but the user has no way to avoid
> it because the outer parens come from the macro template.
>
> Add clippy::double_parens to the existing #![allow(...)] in the
> generated doctest wrapper block. This only covers doctests, but no
> non-doctest code in the tree currently passes a tuple to a printing
> macro.
I think we should either disable with
#[allow(clippy::double_parens, reason = "false positive before 1.92")]
fn update_policy(policy: &mut Policy) {
or disable it globally for all Rust code before 1.92.
Miguel, which one do you think is better?
Best,
Gary
>
> Suggested-by: Gary Guo <gary@xxxxxxxxxxx>
> Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>
>
> diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
> index d61a77219a8c..e9ca56a3b73d 100644
> --- a/scripts/rustdoc_test_gen.rs
> +++ b/scripts/rustdoc_test_gen.rs
> @@ -208,7 +208,7 @@ macro_rules! assert_eq {{
> #[allow(unused)]
> static __DOCTEST_ANCHOR: i32 = ::core::line!() as i32 + {body_offset} + 2;
> {{
> - #![allow(unreachable_pub, clippy::disallowed_names)]
> + #![allow(unreachable_pub, clippy::disallowed_names, clippy::double_parens)]
> {body}
> main();
> }}
>
>
> thanks,