
Those often cause use after free bugs and should be generally avoided. Technically it is safe to have a Twine with >=2 components in a variable but I don't think it is a good pattern to follow. The almost trivial checker comes with elaborated fix-it hints that turn the Twine into a std::string if necessary and otherwise fall back to the original type if the Twine is created from a single value. llvm-svn: 212535
44 lines
1.5 KiB
C++
44 lines
1.5 KiB
C++
//===--- LLVMTidyModule.cpp - clang-tidy ----------------------------------===//
|
|
//
|
|
// The LLVM Compiler Infrastructure
|
|
//
|
|
// This file is distributed under the University of Illinois Open Source
|
|
// License. See LICENSE.TXT for details.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "../ClangTidy.h"
|
|
#include "../ClangTidyModule.h"
|
|
#include "../ClangTidyModuleRegistry.h"
|
|
#include "IncludeOrderCheck.h"
|
|
#include "NamespaceCommentCheck.h"
|
|
#include "TwineLocalCheck.h"
|
|
|
|
namespace clang {
|
|
namespace tidy {
|
|
|
|
class LLVMModule : public ClangTidyModule {
|
|
public:
|
|
void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
|
|
CheckFactories.addCheckFactory(
|
|
"llvm-include-order", new ClangTidyCheckFactory<IncludeOrderCheck>());
|
|
CheckFactories.addCheckFactory(
|
|
"llvm-namespace-comment",
|
|
new ClangTidyCheckFactory<NamespaceCommentCheck>());
|
|
CheckFactories.addCheckFactory(
|
|
"llvm-twine-local",
|
|
new ClangTidyCheckFactory<TwineLocalCheck>());
|
|
}
|
|
};
|
|
|
|
// Register the LLVMTidyModule using this statically initialized variable.
|
|
static ClangTidyModuleRegistry::Add<LLVMModule> X("llvm-module",
|
|
"Adds LLVM lint checks.");
|
|
|
|
// This anchor is used to force the linker to link in the generated object file
|
|
// and thus register the LLVMModule.
|
|
volatile int LLVMModuleAnchorSource = 0;
|
|
|
|
} // namespace tidy
|
|
} // namespace clang
|