CheckName retrieived during construction is a reference to keys stored
inside ClangTidyCheckFactories, which isn't guranteed to outlive the check.
Details
- Reviewers
hokein PiotrZSL njames93 - Commits
- rG2b240cc377b5: [tidy] Expose getID to tidy checks
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
see https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clang-tidy/ClangTidy.cpp#L638 for such a pattern, clangd also initializes checks with a similar approach.
The fix looks good.
We also have a CheckName field in the base class ClangTidyCheck, however that's field is private, we can't not access, we could consider make it protected (I think that's probably out of the scope of this patch).
In this example the factory outlives the check so there is no possible use after free.
In regard to this change, I think that this member can actually be removed entirely as we can get the name of the check using the getID virtual function.
Sorry you're right, I thought checks created in https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clang-tidy/ClangTidy.cpp#L660 would become part of the return value, but instead they're dropped on the floor.
but nevertheless, clangd has this pattern in https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clangd/ParsedAST.cpp#L479. I am happy to change the pattern in clangd as well, but I don't think there's anything requiring users to keep the "factory" around in the contract.
In regard to this change, I think that this member can actually be removed entirely as we can get the name of the check using the getID virtual function.
made it protected and used it instead.