[GIT PULL] Rust fixes for 6.15 merge

[GIT PULL] Rust fixes for 6.15 merge

[Miguel Ojeda]

Hi Linus,

A small fix due to a typo during merge.

Since Andrei had already sent a fix for it, I am sending this as a PR in
case you prefer that, but of course please feel free to directly apply
it as a patch instead.

Thanks!

Cheers,
Miguel

The following changes since commit 4e82c87058f45e79eeaa4d5bcc3b38dd3dce7209:

  Merge tag 'rust-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux (2025-03-30 17:03:26 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux.git tags/rust-fixes-6.15-merge

for you to fetch changes up to c1f4534b213d7be41b5d8b815a42d201a8f2978f:

  scripts: generate_rust_analyzer: fix pin-init name in kernel deps (2025-03-31 10:50:54 +0200)

----------------------------------------------------------------
Rust fixes for v6.15 merge

Fix 'generate_rust_analyzer.py' due to typo during merge.

----------------------------------------------------------------
Andrei Lalaev (1):
      scripts: generate_rust_analyzer: fix pin-init name in kernel deps

 scripts/generate_rust_analyzer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [GIT PULL] Rust fixes for 6.15 merge

[Linus Torvalds]

On Mon, 31 Mar 2025 at 05:29, Miguel Ojeda <ojeda@kernel.org> wrote:
>
> A small fix due to a typo during merge.

Well, duh.

Sometimes I have too much copy-paste, in this case I obviously didn't
have enough of it, and just fixed the conflict - incorrectly - by
hand.

I obviously didn't see any bad effects of this typo in my build
testing, which means that clearly this rust-analyzer thing isn't
getting exercised by my normal build.

Now that I know about the typo, I can see the error with

    make rust-analyzer

and it's not like I'm going to add this to my normal build rules, but
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.

Thanks,
              Linus

Re: [GIT PULL] Rust fixes for 6.15 merge

[pr-tracker-bot]

The pull request you sent on Mon, 31 Mar 2025 14:29:26 +0200:

> https://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux.git tags/rust-fixes-6.15-merge

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/08733088b566b58283f0f12fb73f5db6a9a9de30

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Rust fixes for 6.15 merge

[Miguel Ojeda]

On Mon, Mar 31, 2025 at 8:33 PM Linus Torvalds
<torvalds@linux-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