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: <CAHk-=whkdbFkeZdV3-wFUEcs8JXy=066gNNhTjh5atmurTVqrg@mail.gmail.com>
Date: Fri, 3 Oct 2025 19:17:03 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: John Hubbard <jhubbard@...dia.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Dave Airlie <airlied@...il.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Sima Vetter <sima@...ll.ch>, 
	dri-devel <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.18-rc1

On Fri, 3 Oct 2025 at 18:54, John Hubbard <jhubbard@...dia.com> wrote:
>
> The main complaint with rustfmt is that it is extremely twitchy and
> unstable with respect to one-line, vs. multi-line output.
>
> *Especially* with "use" statements.

The reason I'd like to fix the rules for "use" statements in
particular is that they do get a rather high rate of conflicts, and
then the "multiple entries per line" is actually very annoying
(because the merge turns into a "figure out small change within a
line" rather than "one line from side A, one line from side B").

And that's not because "use" lines are bad - it's actually pretty
natural, and is very similar to what we see with #include lines in C
files. Those too get much higher rate of conflicts than normal code,
and it simply isn't a problem: the conflicts are trivial to resolve.

Because unlike normal code where different people typically work on
different functions etc, the header includes - and for Rust, the "use"
lines - are kind of that shared area where everybody who makes a
change does so in the same place.

So conflicts in that area are normal and expected, and not generally a
sign of any problem.

But then that "small-items" rule makes for extra pain in this area.

Is it a _huge_ pain? No. But it's an unnecessary annoyance, I feel.

IOW, I really think "use" is fundamentally somewhat different from the
other Rust cases.

            Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ