Extract code that forces linking to the separate header and include it in both plugin and standalone tool
Details
- Reviewers
JonasToth alexfh lebedev.ri aaron.ballman hokein - Commits
- rG37512e58baf9: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
rGe74d487be8cb: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
rCTE349131: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
rL349131: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
rL349038: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
rCTE349038: [clang-tidy] Share the forced linking code between clang-tidy tool and plugin
Diff Detail
Event Timeline
- Please always upload all patches with full context.
- There are two places where this pattern exists - this file, and tool/ClangTidyMain.cpp. It clearly leads to such issues, Can this be reworked to be just one file that is simply included in both places?
- Usually I do that but this time used tortoisesvn to generate the patch...
- Makes sense.
clang-tidy/ClangTidyForceLinker.h | ||
---|---|---|
2 | Standard prologue missing |
Thanks, LG.
You probably may want to wait a bit (a day?) in case others want to comment.
FYI, CMake target property INTERFACE_SOURCES is designed to make this easy.
For each module you would generate a file containing
extern volatile int ${MODULE_NAME}ModuleAnchorSource; static int LLVM_ATTRIBUTE_UNUSED ${MODULE_NAME}ModuleAnchorDestination = ${MODULE_NAME}ModuleAnchorSource;
and then put that generated file in the INTERFACE_SOURCES of each module.
target_sources(${MODULE_NAME} INTERFACE ${THE_GENERATED_FILE}.cpp)
Then, you don't need to maintain it in C++ like this. It is DRY because the target_link_libraries entry for the library is what causes the symbol to be used.
That sounds like a better solution, but i think the current pattern is common in LLVM, maybe @aaron.ballman or @alexfh could share their opinion on this one?
Can you say where else it is common in LLVM? I'm curious. Maybe those places could be changed too.
My "is common" is not quantified, I have seen it before :)
From grepping "extern volatile":
- clang-tidy a lot
- clang/lib/Tooling/CompilationDatabase.cpp:398
- clang/lib/Tooling/Execution.cpp:100
- clang/tools/libclang/CIndex.cpp:8681
- clang/tools/libclang/CIndex.cpp:8675
Thats probably all places or is same idiom implementable with something else?
One thing: Could you please check the utility-scripts in clang-tidy that create new checks, if they need adjustments? Not sure if we have something in there that relies on the old structure.
As far as I see these scripts do not touch 'tool' or 'plugin' folders at all, only the specific module, docs and tests.
LGTM, chatted with steveire on IRC: blocking this for a better cmake based solution makes no sense. So your free to commit :)
clang-tidy/plugin/ClangTidyPlugin.cpp | ||
---|---|---|
-91 | It seems it had to go after #include "clang/Config/config.h" to have MPI checks enabled... |
clang-tidy/plugin/ClangTidyPlugin.cpp | ||
---|---|---|
-91 | The includes should be auto-sorted by clang-format, so if that header needs some headers, |
clang-tidy/plugin/ClangTidyPlugin.cpp | ||
---|---|---|
-91 | True. Will fix tomorrow asap. |
I have reverted this in r349121 as it has been causing the PS4 bots to be red for hours now.
clang-tidy/ClangTidyForceLinker.h | ||
---|---|---|
12 | I'm adding them together with the include. |
clang-tidy/plugin/ClangTidyPlugin.cpp | ||
---|---|---|
-91 | Damn, "config.h" is special and can only be included once. |
Standard prologue missing