Annotate facade header with IWYU export annotation#3027
Annotate facade header with IWYU export annotation#3027hzeller wants to merge 1 commit intoboostorg:developfrom
Conversation
Without that annotation, tools such as `clang-tidy` or the `clangd` language server (as well as many other tools) will complain about headers not directly providing a symbol if users include `beast.hpp`; With this annotation, they know. Documentation IWYU https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md#iwyu-pragma-begin_exportsend_exports Documentation llvm include cleaner/clang-tidy/clangd https://clangd.llvm.org/design/include-cleaner#iwyu-pragmas Signed-off-by: Henner Zeller <h.zeller@acm.org>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3027 +/- ##
===========================================
+ Coverage 93.09% 93.11% +0.02%
===========================================
Files 176 176
Lines 13647 13647
===========================================
+ Hits 12704 12708 +4
+ Misses 943 939 -4 see 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
Does IWYU not honour -isystem includes (e.g. via CMake SYSTEM includes)? |
|
Often, warnings for But here we have a different situation, and want to guide warnings in the project itself: IWYU marks includes relevant or not given if they provide a symbol directly in a particular header (and by default it does not follow further includes). That makes sure that symbols don't come from transitive dependencies (accidental visibility of symbols due to the textual concatenation of C headers, the very thing that IWYU wants to help prevent). So if we have a header that is indeed meant to provide a symbol one nest-level deeper, we can annotate it like what I've done here. |
|
This looks benign |
Thank you. It's more clear to me now that this is not "silencing warnings" but annotating the facade header(s) specifically. |
|
@hzeller, I'm using clangd-20 and clang-tidy-20 with the |
|
I’m closing this for now as I wasn’t able to reproduce the reported issue. I’d appreciate it if the OP could provide a bit more information so we can investigate further. |
They are often meant to be included as a single header that then internally includes all the internal headers. However, the single headers don't provide the necessary IWYU annotations for `misc-include-cleaner` to give proper guidance. So for now, misc-include-cleaner warnings w.r.t. boost are more noise then useful. I have a few boost upstream PRs open, but it either goes slow to review, or they require met to show that it is helping, which I didn't have time to yet. Even once all these are merged, we need to wait for them to show up in a released version. (e.g. boostorg/geometry#1427 boostorg/beast#3027 ) Signed-off-by: Henner Zeller <h.zeller@acm.org>
4 participants
Without that annotation, tools such as
clang-tidyor theclangdlanguage server (as well as many other tools) will complain about headers not directly providing a symbol if users includebeast.hpp; With this annotation, they know.Documentation IWYU
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md#iwyu-pragma-begin_exportsend_exports
Documentation llvm include cleaner/clang-tidy/clangd https://clangd.llvm.org/design/include-cleaner#iwyu-pragmas