On Tue, Apr 18, 2023 at 6:28 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > + Florent Hi there! > Joel, Florent is doing some cool stuff with clangd and kernels (check > out the demo at go/linux-kernel-vscode). I'm pushing Florent to Apologies for folks outside Google, this is an internal link to a kernel dev setup I originally created for myself, then for my team and apparently more and more people are starting to use it internally. :) If there's enough appetite for it externally too, I'll try to open-source it someday. Anyway, in the context of this conversation, it's just something that uses clangd. :) > publish some of the cool stuff he's been working on externally because > it is awesome. ;) > > Florent, have you seen any such issues such as what Joel reported below? Yes, I've seen this problem a bunch of times. Afaiu, Clangd operates under the assumption that every source file is a valid compilation unit. My understanding is that it's generally a good practice to keep things that way and I wouldn't be surprised if the userspace Chrome code-base Joel saw enforces this (iirc, it's a rule for Google-internal C++ too, all headers must be interpretable independently). However, from the perspective of the C spec, anything can be included anywhere and a C file can only make sense if it's included after/before certain other things are defined/included. Spontaneously, I would call these ".inc" rather than ".h" or ".c" because I would expect a source file to be always valid and this suffix makes it clearer they depend on their context, but as a matter of fact source files that don't compile when interpreted individually are quite common in the kernel tree. Other examples that have been reported to me include a lot of kernel/sched/*, since many of these files (including .c files) are included from kernel/sched/build_policy.c in a specific order to form one big compilation unit. Unfortunately, I don't know of any solution. :( This feels like a limit of C or compile_commands.json to me. "compile commands" can not be enough to interpret any file, clangd would need a way to express "interpret this file as if it were included in that spot of that compilation unit" and maybe even need a bunch of heuristics to choose one such include spot. I don't know if clangd has any plan to address this and so far I've just lived with these error squiggles.
