As part of our development practices, we generally (want to) enforce strict dependency management. That means directly including public headers for everything (macros, structs, functions, etc.) used within a given source/header file. And furthermore, require explicit direct dependency declarations in the build configurations (pretty much an essential requirement for hermetic / reproducible builds, software bills-of-material, etc.). QPC uses the "one public header" (qpc.h) pattern which fires up a very large number of linting errors pertaining to all the things that this header brings in from its internal private inclusions. The most widely used method to tell checkers about this pattern is to use IWYU pragmas. For example, this informs the checkers (and documents for developers) that things declared in indirectly included headers should be considered as exports of "qpc.h" and that "qpc.h" is the top-level public header to be included to use those things:
#ifndef QPC_H_
#define QPC_H_
//============================================================================
// IWYU pragma: begin_exports
#include "qp_port.h" // QP port from the port directory
#include "qsafe.h" // QP Functional Safety (FuSa) Subsystem
#ifdef Q_SPY // software tracing enabled?
#include "qs_port.h" // QS/C port from the port directory
#else
#include "qs_dummy.h" // QS/C dummy (inactive) interface
#endif
// IWYU pragma: end_exports
....Another useful IWYU pragma is "private" which marks a header as only include'able by explicit "friends", which is a nice protection mechanism for non-hermetic headers (that should also be recommended for the user-provided "qp_config.h" header).
There isn't really a downside here since those pragmas are just ignored comments otherwise. Common checkers that support it are, of course, the original "include-what-you-use" tool, clangd, and clang-tidy (but I'm also aware of others that I cannot disclose).
As part of our development practices, we generally (want to) enforce strict dependency management. That means directly including public headers for everything (macros, structs, functions, etc.) used within a given source/header file. And furthermore, require explicit direct dependency declarations in the build configurations (pretty much an essential requirement for hermetic / reproducible builds, software bills-of-material, etc.). QPC uses the "one public header" (qpc.h) pattern which fires up a very large number of linting errors pertaining to all the things that this header brings in from its internal private inclusions. The most widely used method to tell checkers about this pattern is to use IWYU pragmas. For example, this informs the checkers (and documents for developers) that things declared in indirectly included headers should be considered as exports of "qpc.h" and that "qpc.h" is the top-level public header to be included to use those things:
Another useful IWYU pragma is "private" which marks a header as only include'able by explicit "friends", which is a nice protection mechanism for non-hermetic headers (that should also be recommended for the user-provided "qp_config.h" header).
There isn't really a downside here since those pragmas are just ignored comments otherwise. Common checkers that support it are, of course, the original "include-what-you-use" tool, clangd, and clang-tidy (but I'm also aware of others that I cannot disclose).