The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
In -fdelayed-template-parsing mode, templates that aren't used are not parsed
at all. For some diagnostic plugins, this is a problem since they want to
analyse the contents of the template function body. What has been suggested
on cfe-dev [1] is to explicitly parse interesting templates in
HandleTranslationUnit(); IWYU does this for example [2].
This is workable, but since the delayed parsing doesn't run below a call to
ParseTopLevelDecl(), no DestroyTemplateIdAnnotationsRAIIObj object is on the
stack to clean up TemplateIds that are created during parsing. To fix this,
let ~Parser() clean them up in delayed template parsing mode instead of
leaking (or asserting in +Assert builds).
(r219810, relanded in r220400, fixed the same problem in incremental processing
mode; the review thread of r219810 has a good discussion of the problem.)
To test this, give the PrintFunctionNames plugin a flag to force parsing
of a template and add a test that uses it in -fdelayed-template-parsing mode.
Without the Parser.cpp change, that test asserts.
1: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038415.html
2: https://code.google.com/p/include-what-you-use/source/detail?r=566
llvm-svn: 237531
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
- Plugins don't need to export _ZN4llvm8Registry*.
- Win32.DLL cannot merge common symbols among DLLs. Static members in llvm::Registry should be instantiated in a parent.
llvm-svn: 212821
This flag is set by most other tools and avoids extra stat() calls. The
frontend will diagnose anyway as it performs the check atomically while opening
files at point of use.
We could probably make Driver::CheckInputsExist default to false and only
enable it in the main 'clang' binary, or even better only perform the checks if
we know the tool is external but that needs more thought.
llvm-svn: 212585
Update the strategy in r212083 to try JIT first and otherwise fall back to the
interpreter. This gives the best of both worlds and still builds fine with no
targets enabled.
Requires supporting changes from LLVM r212086.
llvm-svn: 212087
Fixes the build when no targets are selected, or no native target is built.
This also better matches up with the description/title of the example and
demonstrates how clang can be used to run C++ on constrained environments
without file IO or executable memory permissions (e.g. iOS apps).
A comment is added explaining how to extend the demo with JIT support as
needed.
llvm-svn: 212083
All callers were passing in "a.out" or garbage so a sensible default works fine
here as a cleanup.
This also brings about the possibility of adapting the value based on the
driver's compatibility mode in future.
The setting can still be changed via Driver::DefaultImageName as needed.
llvm-svn: 208926
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
When CLANG_BUILD_EXAMPLES is not on we set the EXCLUDE_FROM_ALL
directory property for the examples/ directory to tell CMake not to
build them by default. The AddLLVM.cmake APIs are not aware of this and
try to install targets that are not built. This does not cause an
install-time error because CMake excludes the directory from the default
installation. However, now that installation attaches targets to the
LLVMExports export set CMake-based applications that find_package(LLVM)
fail because the example plugin binary is not available.
Tell the AddLLVM.cmake APIs to exclude the examples from installation by
setting the EXCLUDE_FROM_ALL variable they check.
Patch by Brad King!
llvm-svn: 201799
Also, remove library dependencies for the sample analyzer-plugin. The only
library changes that would require a rebuild should be in headers, which
should already implicitly be marked as dependencies.
llvm-svn: 201350
Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.
This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.
Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.
Reviewers: jordan_rose, krememek
Reviewed By: jordan_rose
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2557
llvm-svn: 201186
This moves the code to Job.cpp, which seems like a more natural fit,
and replaces the "is this a JobList? is this a Command?" logic with
a virtual function call.
It also removes the code duplication between PrintJob and
PrintDiagnosticJob and simplifies the code a little.
There's no functionality change here, except that the Executable is
now always printed within quotes, whereas it would previously not be
quoted in crash reports, which I think was a bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D1653
llvm-svn: 190620
NAKAMURA Takumi