Conditionally compile the parts of clang-tidy which depend on the static
analyzer.
Funnily enough, I made the patch to exclude this from the build in 2013,
and it was committed with the comment that the tool should not be fully
excluded, but only the parts of it which depend on the analyzer should
be excluded.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130617/081797.html
This commit implements that idea.
Reviewed By: aaron.ballman
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D52334
llvm-svn: 343528
This patch introduces index benchmarks on top of the proposed LLVM
benchmark pull.
Reviewed By: sammccall, lebedev.ri
Differential Revision: https://reviews.llvm.org/D51090
llvm-svn: 342026
Exit with a non-zero value in case any of the underlying clang-tidy
invocations exit with a non-zero value.
This is useful in case WarningsAsErrors is enabled for some of the
checks: if any of those checks find something, the exit status now
reflects that.
Also add the ability to use run-clang-tidy.py via lit, and assert that
the exit code is not 0 when modernize-use-auto is triggered
intentionally.
Reviewers: alexfh, aaron.ballman
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D44366
llvm-svn: 327854
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
Support running the extra clang tool tests when the static analyzer
is disabled. Disable the relevant clang-tidy tests and one include-fixer
test that require it to work.
Previously, the tests were disabled entirely with
CLANG_ENABLE_STATIC_ANALYZER being false. Now, the tests are being
enabled and the relevant tests are excluded and marked unsupported
appropriately.
In order to disable clang-tidy tests, the whole test directory is added
to the exclude lists, to avoid having to explicitly add 'REQUIRES' line
to every single test. If the other solution is preferable, I can update
the patch.
The yamldb_plugin include-fixer test is also updated to be disabled
without static analyzer. It fails in that case because clang is not
outputting a replacement suggestion -- but I don't know the exact
reason why it does not do that.
Differential Revision: https://reviews.llvm.org/D37188
llvm-svn: 311983
Prepend the clang library directory (determined using SHLIBDIR, alike
in clang) to the LD_LIBRARY_PATH to ensure that just-built clang
libraries will be used instead of a previous installed version.
When a stand-alone build is performed, LLVM_LIBS_DIR contains the path
to installed LLVM library directory. The same directory frequently
contains a previously installed version of clang. SHLIBDIR, on the other
hand, is always the build-tree directory, and therefore contains
the freshly built clang libraries.
In a non-stand-alone build, both paths will be the same and therefore
including them both will not cause any issues.
Differential Revision: https://reviews.llvm.org/D30155
llvm-svn: 309979
For now, it just detects that host is non-Windows and target is msvc.
FIXME: It should be probable for cross compilations. Detect whether target's headers would be available.
llvm-svn: 261814
Summary: The new check will find all functionand variable definitions which may violate cpp one definition rule in header file.
Reviewers: aaron.ballman, alexfh
Subscribers: aaron.ballman, cfe-commits
Patch by Haojian Wu!
Differential Revision: http://reviews.llvm.org/D15710
llvm-svn: 257178
With this, site specific lit configs can inject parameters into the
test scripts if they need site specific parameters.
Next up: enable check_clang_tidy to take a resource dir to enable
non-standard locations for builtin includes.
llvm-svn: 251010
This tool is for interactive exploration of the Clang AST using AST matchers.
It currently allows the user to enter a matcher at an interactive prompt
and view the resulting bindings as diagnostics, AST pretty prints or AST
dumps. Example session:
$ cat foo.c
void foo(void) {}
$ clang-query foo.c --
clang-query> match functionDecl()
Match #1:
foo.c:1:1: note: "root" binds here
void foo(void) {}
^~~~~~~~~~~~~~~~~
1 match.
Differential Revision: http://llvm-reviews.chandlerc.com/D2098
llvm-svn: 194227
Test-time dependencies now live within test/clang-replace/Inputs which is more
in line with llvm and clang test suites.
Added 'Inputs' to the lit config's 'exclude' list as with llvm's lit.cfg since
test-time dependencies should not have any lit scripts within.
llvm-svn: 189047
NOTE: You may need to run 'make clean' or 'ninja -t clean' etc!!! This
is due to really nasty bug/interactions between
CMake/configure/make/Ninja/LIT...
This commit tries to back out the support for generating test cases as
part of the build system due to the issues I brought up in post-commit
review:
1) It adds a *lot* of complexity and fragility to the build system. See
the number of commits required to try to get all the bots happy.
2) It isn't really necessary -- we can already run scripts to generate
things with the RUN lines of a test.
3) It makes the tests somewhat harder to debug as they cross between
more domains.
4) In almost all cases it isn't really needed or it can be done directly
using the preprocessor.
I should have been more proactive reviewing this, and I'm really sorry
about the churn here. =/ To help keep track of what commits are going
where, this backs out most of the non-test-changes from these revisions:
r176397
r176373
r176293
r176184
r175744
r175624
r175545
r175544
There were several trivial or cleanup changes to the lit files or other
files. Some of these looked ok, but I didn't try to tease them apart...
Edwin, if you know what to look for, please carry on with the cleanups
there, and sorry for hosing stuff here but I'm not much of a Python
person, and so I was erring on the side of cautiously backing out the
change.
I've tried to preserve the test changes everywhere I could, but review
is appreciated here in case I missed some.
I then re-wrote the tests to use the preprocessor rather than python to
expand to the various bits of code. The nicest part of this is that now
all the files are just C++ code. They edit and behave like C++ code,
etc. RUN lines with different -D flags are used to run the same test
over multiple different configurations, and includes bracketed in
special defines are used to flesh out a collection of standard interface
stubs to test interactions between pieces. These probably aren't perfect
yet, but I think its an improvement (at least in terms of build system
complexity) and will hopefully be a useful demonstration of the
technique I prefer for these types of tests.
llvm-svn: 176627
* Fixed a comment typo
* Changed 'autogen' to 'generated-tests'
* Made the clean target not fail if the 'generated-tests' directory
doesn't already exist.
llvm-svn: 175624
autoconf and CMake flavours both updated to auto-generate files for use
in cpp11-migrate's LIT tests.
Auto-generated files are placed in the build directory under
test/cpp11-migrate/autogen. The directory structure past this point
mirrors the structure in the source directory under test/cpp11-migrate.
A lit.site.cfg is generated in test/cpp11-migrate/autogen to describe
the new test suite. When LIT runs, it runs the standard testsuite and
now also the auto-generated testsuite.
llvm-svn: 175544
With this we can build and test the remove-cstr-calls tool which should
serve as a good example of how to add tools and their tests to the
repository.
llvm-svn: 161404
Stephen Kelly