Message-Id: <DF0IGATZ1PFD.C4MMH0JG9IK6@likewhatevs.io>
Date: Wed, 17 Dec 2025 08:03:03 -0500
From: "Pat Somaru" <patso@...ewhatevs.io>
To: "Dmitry Vyukov" <dvyukov@...gle.com>, "Nathan Chancellor"
 <nathan@...nel.org>
Cc: "Nicolas Schier" <nsc@...nel.org>, <patso@...ewhatevs.io>, "Justin
 Stitt" <justinstitt@...gle.com>, <eddyz87@...il.com>, "Linus Torvalds"
 <torvalds@...ux-foundation.org>, <linux-kbuild@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <regressions@...ts.linux.dev>
Subject: Re: [GIT PULL] kbuild changes for v6.19

Hi All,

>> 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.

I would say revert this.

When I was testing this change, I wrote a script to non-interactively
run clangd against all the files in the kernel individually and report if 
there were more errors or fewer and how many files clangd gave up on indexing.

I vaguely recall this script reported there were more errors overall, but also
that there were fewer files which clangd gave up on indexing (i.e. fewer
files where LSP more/less outright does not work)/more files processed
overall.

My understanding of that output was "folks's ide's/clangd works on more files
with this, but there are more errors overall because fewer files are
treated as totally broken/given up on by clangd".

If there are only a handful of problematic files with this, I can see if
there are some common patterns (such as c files including themselves) which 
could be accounted for in the script, but if the outputs of
gen_compile_commands are used as inputs to further automation, both issues 
with the script itself and those in files previously excluded due to the 
omission of compilation database entries are going to be surfaced by this, and
I'm not super confident I could come up with a complete set of fixes for the
latter.

Have a good day,
Pat

On Wed Dec 17, 2025 at 7:07 AM EST, Dmitry Vyukov wrote:
> On Wed, 17 Dec 2025 at 11:45, Nathan Chancellor <nathan@...nel.org> wrote:
>>
>> 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.
>
> I am not typing commands in the console, I work on an automated system
> that does not have a notion of "also do these custom changes to the
> source tree at this particular point in the process".
>
>> > 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),
>
> The same stands for e.g. include/linux/sched.h.
> kernel/sched/ext.c is just not a source file, it is a header file effectively.
>
>> 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

Powered by blists - more mailing lists