Re: [GIT PULL] kbuild changes for v6.19

[Nathan Chancellor <nathan@kernel.org>]

On Wed, Dec 17, 2025 at 11:16:37AM +0100, Dmitry Vyukov wrote:
> Yikes! I am trying to workaround this, but this is PITA.
> Entries are not in order, + there are now multiple entries for the
> same source file (yes, files include themselves). This is plain
> broken, and hard to workaround. Even if I find the entry that is
> correct, I can't really tell about it to a clang tool since it accepts
> just the source file name, and there are multiple entries for the same
> file name.
> 
> Does anybody see a reasonable way to undo what this commit is doing?

Does

  $ git revert 9362d34acf91a706c543d919ade3e651b9bd2d6f

not work for you? It is a clean revert for me.

> Thinking about this: I think included source files should be treated
> as include files by anything, rather than added to the database. They
> _are_ include files, and systems should handle include files already.

The commit message of 9362d34acf91 mentions that clangd does not work
properly with the files that are included in kernel/sched/build_policy.c
(such as kernel/sched/ext.c) because there are no entries for them in
compile_commmands.json (so it does not know how to build them), which is
what 9362d34acf91 was trying to fix. I don't use clangd or
compile_commands.json, so I can't say if there is a way for the tool
itself to fix this. Again, unless Pat can come up with some way to work
around this (which I do not personally see at this point), I think we
would be better off just reverting 9362d34acf91 outright and calling the
situation of including .c files within other .c files broken for
compile_commands.json and returning to the status quo from 6.18 and
earlier.

Cheers,
Nathan