Changeset View
Standalone View
libc/utils/LibcTidy/LibcTidyTool.h
- This file was added.
| //===-- LibcTidyTool.h ------------------------------------------*- C++ -*-===// | |||||
| // | |||||
| // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | |||||
| // See https://llvm.org/LICENSE.txt for license information. | |||||
| // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | |||||
| // | |||||
| //===----------------------------------------------------------------------===// | |||||
| #ifndef LLVM_LIBC_UTILS_LIBCTIDY_TOOL_H | |||||
| #define LLVM_LIBC_UTILS_LIBCTIDY_TOOL_H | |||||
| #include "clang/ASTMatchers/ASTMatchFinder.h" | |||||
| #include "clang/Frontend/FrontendActions.h" | |||||
| #include "clang/Tooling/Tooling.h" | |||||
abrachet: Looks like this include isn't needed either | |||||
| #include "llvm/ADT/StringSet.h" | |||||
Not needed? sivachandra: Not needed? | |||||
Not Done ReplyInline ActionsDo we care about a nolint on the previous line? Is that already handled by clang-tidy? abrachet: Do we care about a nolint on the previous line? Is that already handled by clang-tidy? | |||||
This is intended to be quite lightweight so I didn't bother implementing a previous line nolint. I figured that using no-lint is a rare case. However if in the future this becomes cumbersome we could possibly add it in later. PaulkaToast: This is intended to be quite lightweight so I didn't bother implementing a previous line nolint. | |||||
Not Done ReplyInline ActionsSame question as @abrachet: Doesn't clang-tidy already do this? We should avoid writing custom C++ source parsers unless existing clang or other APIs do not serve our purpose. sivachandra: Same question as @abrachet: Doesn't clang-tidy already do this? We should avoid writing custom… | |||||
clang-tidy currently doesn't seem to be written in a way that we can expand on it in our source tree similar to lib tooling. Their nolint code is marked static and only visible here: https://github.com/llvm/llvm-project/blob/cb1ee34e9d32fce84613827693a8ed3aff1d36cf/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp#L270 Their diagnostics consumer is deeply linked to the rest of clang-tidy so we can't pull out the parts we need. PaulkaToast: clang-tidy currently doesn't seem to be written in a way that we can expand on it in our source… | |||||
| class LibcTidyCheck : public clang::ast_matchers::MatchFinder::MatchCallback { | |||||
| public: | |||||
| virtual void registerPPCallbacks(clang::Preprocessor &PP, | |||||
| clang::ast_matchers::MatchFinder &finder){}; | |||||
| virtual void registerMatchers(clang::ast_matchers::MatchFinder &finder){}; | |||||
| }; | |||||
| class LibcTidyActionFactory : public clang::tooling::FrontendActionFactory { | |||||
| public: | |||||
| LibcTidyActionFactory(clang::ast_matchers::MatchFinder &finder, | |||||
| std::vector<std::unique_ptr<LibcTidyCheck>> &checks) | |||||
| : finder(finder), checks(checks) {} | |||||
| std::unique_ptr<clang::FrontendAction> create() override; | |||||
| private: | |||||
| clang::ast_matchers::MatchFinder &finder; | |||||
Not Done ReplyInline ActionsDo we want these to be pure virtual or is there a reason they do nothing? abrachet: Do we want these to be pure virtual or is there a reason they do nothing? | |||||
The registerMatchers might be a good candidate for a pure virtual function. However, registerPPCallbacks is only needed for cases where we need information from the pre-processor, so having an empty implementation there is probably better. In this patch we even have an example of a check that doesn't need a registerMatchers function because we register the AST matchers in the preprocessor callback. That was the motivation for making them do nothing by default. PaulkaToast: The `registerMatchers` might be a good candidate for a pure virtual function. However… | |||||
| std::vector<std::unique_ptr<LibcTidyCheck>> &checks; | |||||
| }; | |||||
| #endif // LLVM_LIBC_UTILS_LIBCTIDY_TOOL_H | |||||
Looks like this include isn't needed either