[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DB768SCZCRVK.1PVRI6EOMGO6V@umich.edu>
Date: Tue, 08 Jul 2025 21:33:47 -0500
From: "Trevor Gross" <tmgross@...ch.edu>
To: Onur Özkan <work@...rozkan.dev>,
<rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-pm@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
<kunit-dev@...glegroups.com>
Cc: <airlied@...il.com>, <simona@...ll.ch>, <ojeda@...nel.org>,
<alex.gaynor@...il.com>, <boqun.feng@...il.com>, <gary@...yguo.net>,
<bjorn3_gh@...tonmail.com>, <lossin@...nel.org>, <a.hindborg@...nel.org>,
<aliceryhl@...gle.com>, <rafael@...nel.org>, <viresh.kumar@...aro.org>,
<gregkh@...uxfoundation.org>, <maarten.lankhorst@...ux.intel.com>,
<mripard@...nel.org>, <tzimmermann@...e.de>, <davidgow@...gle.com>,
<nm@...com>
Subject: Re: [PATCH v4 1/6] rust: switch to `#[expect(...)]` in core modules
On Tue Jul 1, 2025 at 12:35 AM CDT, Onur Özkan wrote:
> This makes it clear that the warning is expected not just
> ignored, so we don't end up having various unnecessary
> linting rules in the codebase.
>
> Some parts of the codebase already use this approach, this
> patch just applies it more broadly.
>
> No functional changes.
>
> Signed-off-by: Onur Özkan <work@...rozkan.dev>
> ---
> diff --git a/rust/kernel/alloc/allocator_test.rs b/rust/kernel/alloc/allocator_test.rs
> index d19c06ef0498..844197d7194e 100644
> --- a/rust/kernel/alloc/allocator_test.rs
> +++ b/rust/kernel/alloc/allocator_test.rs
> @@ -7,7 +7,7 @@
> //! `Cmalloc` allocator within the `allocator_test` module and type alias all kernel allocators to
> //! `Cmalloc`. The `Cmalloc` allocator uses libc's `realloc()` function as allocator backend.
>
> -#![allow(missing_docs)]
> +#![expect(missing_docs)]
>
> use super::{flags::*, AllocError, Allocator, Flags};
> use core::alloc::Layout;
If you spin this again, would you mind adding a comment/`reason` about
why there isn't documentation here?
This is preexisting but something to shift the possible meaning from
"this module shouldn't have documentation" to "it's okay that we don't
document unstable test interfaces" would be helpful.
Thanks,
Trevor
Powered by blists - more mailing lists