[PATCH] rust: allow `clippy::disallowed_names` for doctests

[Miguel Ojeda]

Examples (i.e. doctests) may want to use names such as `foo`, thus the
`clippy::disallowed_names` lint gets in the way.

Thus allow it for all doctests.

In addition, remove it from the existing `expect`s we have in a few
doctests.

This does not mean that we should stop trying to find good names for
our examples, though.

Suggested-by: Alice Ryhl <alic...@google.com>
Link: https://lore.kernel.org/rust-for-linux/aRHSLChi...@google.com/
Signed-off-by: Miguel Ojeda <oj...@kernel.org>
---
rust/kernel/init.rs | 3 +--
rust/kernel/types.rs | 1 -
scripts/rustdoc_test_gen.rs | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs
index e476d81c1a27..899b9a962762 100644
--- a/rust/kernel/init.rs
+++ b/rust/kernel/init.rs
@@ -30,7 +30,7 @@
//! ## General Examples
//!
//! ```rust
-//! # #![expect(clippy::disallowed_names, clippy::undocumented_unsafe_blocks)]
+//! # #![expect(clippy::undocumented_unsafe_blocks)]
//! use kernel::types::Opaque;
//! use pin_init::pin_init_from_closure;
//!
@@ -67,7 +67,6 @@
//! ```
//!
//! ```rust
-//! # #![expect(clippy::disallowed_names)]
//! use kernel::{prelude::*, types::Opaque};
//! use core::{ptr::addr_of_mut, marker::PhantomPinned, pin::Pin};
//! # mod bindings {
diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
index 835824788506..9c5e7dbf1632 100644
--- a/rust/kernel/types.rs
+++ b/rust/kernel/types.rs
@@ -289,7 +289,6 @@ fn drop(&mut self) {
/// # Examples
///
/// ```
-/// # #![expect(clippy::disallowed_names)]
/// use kernel::types::Opaque;
/// # // Emulate a C struct binding which is from C, maybe uninitialized or not, only the C side
/// # // knows.
diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
index 0e6a0542d1bd..be0561049660 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} + 1;
{{
- #![allow(unreachable_pub)]
+ #![allow(unreachable_pub, clippy::disallowed_names)]
{body}
main();
}}
--
2.51.2

[Alice Ryhl]

On Mon, Nov 17, 2025 at 9:07 AM Miguel Ojeda <oj...@kernel.org> wrote:
>
> Examples (i.e. doctests) may want to use names such as `foo`, thus the
> `clippy::disallowed_names` lint gets in the way.
>
> Thus allow it for all doctests.
>
> In addition, remove it from the existing `expect`s we have in a few
> doctests.
>
> This does not mean that we should stop trying to find good names for
> our examples, though.
>
> Suggested-by: Alice Ryhl <alic...@google.com>
> Link: https://lore.kernel.org/rust-for-linux/aRHSLChi...@google.com/
> Signed-off-by: Miguel Ojeda <oj...@kernel.org>

Reviewed-by: Alice Ryhl <alic...@google.com>

[Benno Lossin]

On Mon Nov 17, 2025 at 9:07 AM CET, Miguel Ojeda wrote:
> Examples (i.e. doctests) may want to use names such as `foo`, thus the
> `clippy::disallowed_names` lint gets in the way.
>
> Thus allow it for all doctests.
>
> In addition, remove it from the existing `expect`s we have in a few
> doctests.
>
> This does not mean that we should stop trying to find good names for
> our examples, though.
>
> Suggested-by: Alice Ryhl <alic...@google.com>
> Link: https://lore.kernel.org/rust-for-linux/aRHSLChi...@google.com/
> Signed-off-by: Miguel Ojeda <oj...@kernel.org>

Acked-by: Benno Lossin <los...@kernel.org>

Cheers,
Benno

[Miguel Ojeda]

On Mon, Nov 17, 2025 at 9:07 AM Miguel Ojeda <oj...@kernel.org> wrote:
>
> Examples (i.e. doctests) may want to use names such as `foo`, thus the
> `clippy::disallowed_names` lint gets in the way.
>
> Thus allow it for all doctests.
>
> In addition, remove it from the existing `expect`s we have in a few
> doctests.
>
> This does not mean that we should stop trying to find good names for
> our examples, though.
>
> Suggested-by: Alice Ryhl <alic...@google.com>
> Link: https://lore.kernel.org/rust-for-linux/aRHSLChi...@google.com/
> Signed-off-by: Miguel Ojeda <oj...@kernel.org>

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

Cheers,
Miguel

[John Hubbard]

Is rust-next a rebasing branch? I was going to request a non-empty commit
body, in order to make it more immediately clear what this does. Something
like:

The current set of disallowed names is inherited from clippy's defaults [1],
which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
which so far has no entries for disallowed names.

thanks,
--
John Hubbard

[John Hubbard]

On 11/17/25 1:13 PM, John Hubbard wrote:
> On 11/17/25 1:02 PM, Miguel Ojeda wrote:
>> On Mon, Nov 17, 2025 at 9:07 AM Miguel Ojeda <oj...@kernel.org> wrote:

...

> Is rust-next a rebasing branch? I was going to request a non-empty commit
> body, in order to make it more immediately clear what this does. Something
> like:
>
> The current set of disallowed names is inherited from clippy's defaults [1],
> which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
> which so far has no entries for disallowed names.
>

oops, left out the link. Here:

[1] https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_names


thanks,
--
John Hubbard

[Miguel Ojeda]

On Mon, Nov 17, 2025 at 10:13 PM John Hubbard <jhub...@nvidia.com> wrote:
>
> Is rust-next a rebasing branch? I was going to request a non-empty commit
> body, in order to make it more immediately clear what this does. Something
> like:
>
> The current set of disallowed names is inherited from clippy's defaults [1],
> which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
> which so far has no entries for disallowed names.

What do you mean by "non-empty commit body"? The commit has several
short paragraphs and mentions the `foo` example (precisely to hint at
what the lint does).

But, sure, I am happy to add a Link: tag to the lint -- I typically
add those when enabling a lint (e.g. commit db4f72c904cb ("rust:
enable `clippy::undocumented_unsafe_blocks` lint")).

Cheers,
Miguel

[Miguel Ojeda]

On Mon, Nov 17, 2025 at 10:13 PM John Hubbard <jhub...@nvidia.com> wrote:
>

> The current set of disallowed names is inherited from clippy's defaults [1],
> which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
> which so far has no entries for disallowed names.

As for this paragraph, I am confused why we would want to add it.

This isn't about extending the disallowed names or about how the lint
works in general. It is just about disabling the lint entirely for
doctests.

So adding that paragraph would make it the commit more confusing.

Cheers,
Miguel

[John Hubbard]

On 11/17/25 1:24 PM, Miguel Ojeda wrote:
> On Mon, Nov 17, 2025 at 10:13 PM John Hubbard <jhub...@nvidia.com> wrote:
>>
>> Is rust-next a rebasing branch? I was going to request a non-empty commit
>> body, in order to make it more immediately clear what this does. Something
>> like:
>>
>> The current set of disallowed names is inherited from clippy's defaults [1],
>> which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
>> which so far has no entries for disallowed names.
>
> What do you mean by "non-empty commit body"? The commit has several
> short paragraphs and mentions the `foo` example (precisely to hint at
> what the lint does).
>

Yikes, I misread one of the replies (way too quickly) and completely
missed the commit body, sorry for that.

thanks,
--
John Hubbard

[John Hubbard]

On 11/17/25 1:26 PM, Miguel Ojeda wrote:
> On Mon, Nov 17, 2025 at 10:13 PM John Hubbard <jhub...@nvidia.com> wrote:
>>
>> The current set of disallowed names is inherited from clippy's defaults [1],
>> which are "foo", "baz", and "quux". This may be extended via .clipy.toml,
>> which so far has no entries for disallowed names.
>
> As for this paragraph, I am confused why we would want to add it.
>
> This isn't about extending the disallowed names or about how the lint
> works in general. It is just about disabling the lint entirely for
> doctests.

Yes. But I still thought some context might help, because it wasn't
obvious at first to me (as a Rust learner).

>
> So adding that paragraph would make it the commit more confusing.
>

OK, I'll accept that judgment call. :)

thanks,
--
John Hubbard