linux-kernel - Re: [PATCH 18/19] Documentation: rust: discuss `#[expect(...)]` in the guidelines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72k21-kke0XFNf0iQ5gpECjAtEPg00tm-JwpNjff34n5+g@mail.gmail.com>
Date: Tue, 1 Oct 2024 19:11:45 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Trevor Gross <tmgross@...ch.edu>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH 18/19] Documentation: rust: discuss `#[expect(...)]` in
 the guidelines

On Sun, Sep 29, 2024 at 7:11 AM Trevor Gross <tmgross@...ch.edu> wrote:
>
> Would it be good to mention that a reason can be specified with
> `reason = "..."`? I don't think we use this anywhere yet.

I mainly wanted to introduce things "slowly" :)

But I would be happy if we consistently use `reason`, I think it is a
good idea to document those, and perhaps we can get to the point where
we go for `clippy::allow_attributes_without_reason` too.

Relatedly, I also thought about `clippy::allow_attributes`, but due to
conditional compilation and the other reasons mentioned in the docs
added in the series, it is likely not something we can easily do.

Another tangent: I find the `reason` syntax a bit too "busy". I think
in some cases we may just want to write things as if they were "normal
comments" (and multiline and so on). Highlighting in particular ways
could help perhaps. It would have been nice to have something like `//
ALLOW` on top of the attribute, similar to `// SAFETY`, and have the
compiler understand that directly like Clippy nowadays does for `//
SAFETY`, but I guess there are downsides.

Cheers,
Miguel