On Wed, Apr 02, 2025 at 03:46:34AM +0900, Masahiro Yamada wrote: > However, it is annoying to make every header self-contained > "just because we are checking this".
>From my POV itis not "just because we are checking this", I have a very deliberate reason for wanting headers to be self contained: I want the clangd code indexer and editor integration to work fully. When clangd is asked by the editor for a report on a header file it cannot know the missing implicit includes and it's functionality is degraded. It reports fake compilation errors, can't do all the indexing functions, and is generally a bad experience. To be clear the header is parsed and loaded into the database when some C file included it, just the actual editing of the header doesn't work well. This is a very big day-to-day negative for working on the code. I'm frequently annoyed by headers that are pointlessly not self contained. I'd really welcome someone doing a cleanup here. I agree it should not be a hard rule. I was reading the thread you linked to and I'm thinking the approach is not optimal. The only header files that should be checked are ones that are actually used as part of the build with the current kconfig. Christoph is right that there are endless cases where headers should never be parsed outside of specific kconfig settings. So, I'd suggest a better way to run this is first build the kernel, then mine the gcc -MD output (ie stored in the .XX.cmd files) to generate a list of headers that are actually part of the build, then only test those. That eliminates all the kconfig problems. Opt out any special headers that really have a good reason not to be stand alone. Jason
