[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=1QvWpBi8zc_9_irU_GEn_50Fqpmqj3ANKW1WbuOvWOQ@mail.gmail.com>
Date: Sun, 16 Feb 2025 18:22:47 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Charalampos Mitrodimas <charmitro@...teo.net>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, Wedson Almeida Filho <wedsonaf@...il.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH] rust: fix clippy::too-long-first-doc-paragraph
On Sun, Feb 16, 2025 at 2:30 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>
> I don't think that this one is bad. Of course it would be nice if only
> the rendered form would be considered, but there might also be people
> reading it directly in the code, so it could actually be a good idea to
> also keep the raw text short.
>
> In the case of long links, one can easily work around it by just not
> using an inline link. (so having [text with link] and then after the
> paragraph `[text with link]: link`.)
Agreed, I think this one should not be an issue and could in fact be a
good thing.
> This one just seems like a nice-to-have, but not a deal breaker.
Yeah.
> IMO we can enable the lint (since the instance fixed in this patch is
> the only error I get with that lint) and just see how it behaves.
Yeah, I am happy trying that one. If you want to submit the patch
formally, then we can see how it goes.
In general, though, I think for "nursery" lints we may want to be
extra careful, especially if it may look like they will have potential
behavior changes that end up triggering even more changes later until
they settle (e.g. suddenly they change the threshold length or other
heuristics). For now we don't have that much code, so it is OK.
I think eventually we may end up putting some extra lints into a
separate group that can be enabled opt-in, and then promote them as
time passes.
Cheers,
Miguel
Powered by blists - more mailing lists