kernel: Avoid including files outside include guards #4312
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adjusts the way the headers kernel/{yosys,rtlil,register,log}.h include each other to avoid the need of including headers outside of include guards as well as avoiding the inclusion of rtlil.h in the middle of yosys.h with rtlil.h depending on the prefix of yosys.h, and the suffix of yosys.h depending on rtlil.h.
To do this I moved some of the declaration in yosys.h into a new header yosys_common.h. I'm not sure if that is strictly necessary.
Including any of these files still results in the declarations of all these headers being included, so this shouldn't be a breaking change for any passes or external plugins.
My main motivation for this is that ccls's (clang based language server) include guard handling gets confused by the previous way the includes were done. It often ends up treating the include guard as a generic disabled preprocessor conditional, breaking navigation and highlighting for the core RTLIL data structures.
Additionally I think avoiding cyclic includes in the middle of header files that depend on includes being outside of include guards will also be less confusing for developers reading the code, not only for tools like ccls.