linux-kernel - Re: [GIT PULL] Rust fixes for 6.15 merge

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANiq72kkjGVAtWNZjz5VGen4xoVLfRa+Wv399PUO=EfcA4TEfQ@mail.gmail.com>
Date: Tue, 1 Apr 2025 13:02:05 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Rust fixes for 6.15 merge

On Mon, Mar 31, 2025 at 8:33 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> maybe you can give a list of things that I should be doing when I see
> rust merge conflicts so that next time around I'll notice these things
> rather than have silly typo mistakes.

These are the ones we have:

  - `make rustfmtcheck` (or `make rustfmt` to apply): This one you
already know about.

  - `make rust-analyzer`: The one from today.

    Since it just generates a config file "blindly", the config file
could still be completely broken even if the Python script succeeds.
But running it is straightforward and quick, so there is no loss
running it on merge conflicts.

  - `make rustdoc`: What generates e.g. rust.docs.kernel.org.

    It could catch some issues, e.g. "broken intra-doc links".
Warnings would not be a huge deal, but any errors here would be nice
to avoid so that developers and rust.docs.kernel.org can always
generate them.

    This one (for the moment) always re-generates from scratch, but if
you just run it on merge conflicts, it is fairly quick (more or less
like building the Rust code).

  - `make rusttest`: Runs a few userspace-only tests.

    We don't really use or change the feature much, so it is unlikely
you will have any merge conflicts here to begin with, but it is also
quick to run. Perhaps in the future we may reuse the target for more
things.

  - `make CLIPPY=1`: A linter.

    I am not sure about this one, at least for the time being. It
could spot something that is fishy after a merge, especially if you
had to rearrange code, but they are lints after all, and sometimes it
may not be clear what to do (e.g. `#[allow(...)]` locally) and you may
hit bugs or false positives.

    We will probably end up defining a set of lints that we want to
really, really keep clean, and then that would be what you could run
on conflicts, and leave others to something like `W=` levels.

    Note that if you decide to try it, it is a different binary, like
a twin of the compiler, which means rebuilding Rust code. Also, if you
do `WERROR=y` you may want `KRUSTFLAGS=-Wwarnings` when running Clippy
if there happens to be a lint not cleaned up somewhere (e.g. right now
there is one, its patch going through trees).

Thanks!

Cheers,
Miguel