[PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[John Hubbard]

The kernel fmt! proc macro wraps each format argument as &(arg).
Passing a tuple like (a, b) produces &((a, b)) after expansion,
which Clippy flags as double_parens. This is a false positive,
fixed in Clippy 1.92 (rust-lang/rust-clippy#15939), but the
minimum toolchain (1.78) still triggers it.

Add a local #[allow] with a reason attribute on the affected
doctest function so it can be removed once the minimum toolchain
moves past 1.92.

Changes in v2:
* Drop the v1 approach of splitting format arguments.

* Drop the rustdoc_test_gen.rs blanket suppress (was posted
  inline during discussion, never sent as a formal patch).

* Instead, add a local #[allow(clippy::double_parens)] with a
  reason attribute on the specific doctest, per Gary and Miguel's
  suggestions.

v1 is here:
    https://lore.kernel.org/20260304195330.185829-1-jhubbard@nvidia.com

John Hubbard (1):
  rust: cpufreq: suppress clippy::double_parens in Policy doctest

 rust/kernel/cpufreq.rs | 1 +
 1 file changed, 1 insertion(+)


base-commit: 80234b5ab240f52fa45d201e899e207b9265ef91
-- 
2.53.0

[PATCH v2 1/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[John Hubbard]

The kernel fmt! proc macro wraps each format argument as &(arg). Passing
a tuple such as (a, b) produces &((a, b)) after expansion. Clippy flags
that as double_parens, but it is a false positive fixed in Clippy 1.92
(rust-lang/rust-clippy#15939).

Suppress the warning on the affected doctest function with a reason
attribute so it can be removed once the minimum toolchain moves
past 1.92.

Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 rust/kernel/cpufreq.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index 76faa1ac8501..52fe061fc85e 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -401,6 +401,7 @@ pub fn to_table(mut self) -> Result<TableBox> {
 /// ```
 /// use kernel::cpufreq::{DEFAULT_TRANSITION_LATENCY_NS, Policy};
 ///
+/// #[allow(clippy::double_parens, reason = "false positive before 1.92")]
 /// fn update_policy(policy: &mut Policy) {
 ///     policy
 ///         .set_dvfs_possible_from_any_cpu(true)
-- 
2.53.0

Re: [PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[Miguel Ojeda]

On Thu, Mar 12, 2026 at 5:19 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> The kernel fmt! proc macro wraps each format argument as &(arg).
> Passing a tuple like (a, b) produces &((a, b)) after expansion,
> which Clippy flags as double_parens. This is a false positive,
> fixed in Clippy 1.92 (rust-lang/rust-clippy#15939), but the
> minimum toolchain (1.78) still triggers it.
>
> Add a local #[allow] with a reason attribute on the affected
> doctest function so it can be removed once the minimum toolchain
> moves past 1.92.

Cc'ing Rafael and Viresh -- do you want me to take this via rust-fixes
to clean the build log? I am planning to send a PR to Linus for this
-rc.

Thanks!

Cheers,
Miguel

Re: [PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[Viresh Kumar]

On 12-03-26, 07:03, Miguel Ojeda wrote:
> On Thu, Mar 12, 2026 at 5:19 AM John Hubbard <jhubbard@nvidia.com> wrote:
> >
> > The kernel fmt! proc macro wraps each format argument as &(arg).
> > Passing a tuple like (a, b) produces &((a, b)) after expansion,
> > which Clippy flags as double_parens. This is a false positive,
> > fixed in Clippy 1.92 (rust-lang/rust-clippy#15939), but the
> > minimum toolchain (1.78) still triggers it.
> >
> > Add a local #[allow] with a reason attribute on the affected
> > doctest function so it can be removed once the minimum toolchain
> > moves past 1.92.
> 
> Cc'ing Rafael and Viresh -- do you want me to take this via rust-fixes
> to clean the build log? I am planning to send a PR to Linus for this

Thanks for cc'ing us. Yeah, please take it.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

Re: [PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[Miguel Ojeda]

On Thu, Mar 12, 2026 at 7:07 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> Thanks for cc'ing us. Yeah, please take it.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Thanks for the very quick reply! Will do.

Cheers,
Miguel

Re: [PATCH v2 0/1] rust: cpufreq: suppress clippy::double_parens in Policy doctest

[Miguel Ojeda]

On Thu, Mar 12, 2026 at 5:19 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> The kernel fmt! proc macro wraps each format argument as &(arg).
> Passing a tuple like (a, b) produces &((a, b)) after expansion,
> which Clippy flags as double_parens. This is a false positive,
> fixed in Clippy 1.92 (rust-lang/rust-clippy#15939), but the
> minimum toolchain (1.78) still triggers it.
>
> Add a local #[allow] with a reason attribute on the affected
> doctest function so it can be removed once the minimum toolchain
> moves past 1.92.

Applied to `rust-fixes` -- thanks everyone!

    [ We may end up deciding to support per-version Clippy lints, in which
      case we will need [3].

      In the future, if [4] gets fixed, we may be able to use
      `Delimiter::None` as Gary suggested in [5].

      Link: https://lore.kernel.org/rust-for-linux/20260307170929.153892-1-ojeda@kernel.org/
[3]
      Link: https://github.com/rust-lang/rust/issues/67062 [4]
      Link: https://lore.kernel.org/rust-for-linux/DGUA5GY2DGYN.3PG0FKLG7GFN1@garyguo.net/
[5]

        - Miguel ]

    [ Reworded to replace GitHub-like short link with full URLs in Link tags.
      Reworded reason string to match the style of a couple others we have
      elsewhere. - Miguel ]

The lint doesn't trigger in stable from what I can see -- it seems to
appear with the merge of our tag that contained the `syn` rewrite
merged in 7.0, so I didn't add:

  Cc: stable@vger.kernel.org # Needed in 6.18.y and later

but we could if needed (e.g. if we happen to backport the `syn` rewrite).

Cheers,
Miguel