KyleFromKitware added a comment. In D142123#4066676 <https://reviews.llvm.org/D142123#4066676>, @aaron.ballman wrote:
> It doesn't have to -- for example, we can name the guard based on the path to > the header. e.g., `foo/include/bar/baz.h` could use `FOO_INCLUDE_BAR_BAZ_H` > as the header guard. But then this would conflict with `LLVMHeaderGuardCheck` - the LLVM check would suggest one thing and the generic check would suggest something different. > It's orthogonal except for the design concerns. Basically, I don't think we > should have one check for "go to header guards" and another check for "go to > pragma once" -- IMO we should have one check to do either approach. @njames93 > is correct that a common use case for clang-tidy is "enable all checks" so > having two checks that do opposite things gets awkward in practice. See above - a generic check would also cause a conflict if they blindly enabled all checks. I think that no matter what we do here, enabling all checks is going to cause a conflict of some kind. The only way to avoid this is if we overhaul the existing `HeaderGuardCheck` and make its naming convention configurable by a configuration option as opposed to having to extend the C++ class to calculate the name. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142123/new/ https://reviews.llvm.org/D142123 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
