D60974 added tests which incorrectly assume that llvm-readelf is available. This is a bad assumption, it should instead declare the dependency explicitly in the tests.
llvm-svn: 364855
Commit r363496 ("[Clang] Harmonize Split DWARF options with llc",
2019-06-15) introduced the use of llvm-dwarfdump in the clang tests,
so ensure the clang tests are dependent on llvm-dwarfdump.
llvm-svn: 364021
- CodeGen/flatten.c will fail under new PM becausec the new PM AlwaysInliner
seems to intentionally inline functions but not call sites marked with
alwaysinline (D23299)
- Tests that check remarks happen to check them for the inliner which is not
turned on at O0. These tests just check that remarks work, but we can make
separate tests for the new PM with -O1 so we can turn on the inliner and
check the remarks with minimal changes.
Differential Revision: https://reviews.llvm.org/D62225
llvm-svn: 363846
dependencies over a JSON compilation database
This commit introduces an outline for the clang-scan-deps tool that will be
used to implement fast dependency discovery phase using implicit modules for
explicit module builds.
The initial version of the tool works by computing non-modular header dependencies
for files in the compilation database without any optimizations
(i.e. without source minimization from r362459).
The tool spawns a number of worker threads to run the clang compiler workers in parallel.
The immediate goal for clang-scan-deps is to create a ClangScanDeps library
which will be used to build up this tool to use the source minimization and
caching multi-threaded filesystem to implement the optimized non-incremental
dependency scanning phase for a non-modular build. This will allow us to do
benchmarks and comparisons for performance that the minimization and caching give us
Differential Revision: https://reviews.llvm.org/D60233
llvm-svn: 363204
Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage.
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
llvm-svn: 362328
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
llvm-svn: 361790
When plugins aren't enabled, don't try to run plugins tests. Don't
enable plugins unconditionally based on the platform, instead check
if LLVM shared library is actually being built which may not be the
case for every host configuration, even if the host itself supports
plugins.
This addresses test failures introduced by r360891/D59464.
Differential Revision: https://reviews.llvm.org/D62050
llvm-svn: 360991
Buildbots complained that they couldn't find the newly added plugins.
The solution was to move the check-clang cmake target closer to the bottom of
the file, after the new dependencies are added.
Differential Revision: https://reviews.llvm.org/D59464
llvm-svn: 360891
Also, I moved the existing analyzer plugin to test/ as well, in order not to
give the illusion that the analyzer supports plugins -- it's capable of handling
them, but does not _support_ them.
Differential Revision: https://reviews.llvm.org/D59464
llvm-svn: 360799
The Tooling tests do have a lit.local.cfg with
if not config.root.clang_staticanalyzer:
config.unsupported = True
so what's wrong isn't the missing dep, but that lit prints a warning for
the binary missing. This will need a different kind of fix.
llvm-svn: 359739
check-clang (the target that runs all clang tests) used to
only depend on clang-check (a binary like clang-tidy,
clang-refactor, etc) if the static analyzer is enabled.
However, several lit tests call clang-check unconditionally,
so always depend on it.
Fixes a "could not find clang-check" lit warning in clean builds with
the static analyzer disabled.
Also sort the deps in the CMake file and put just one dep on each line.
Differential Revision: https://reviews.llvm.org/D61324
llvm-svn: 359717
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421
Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille
Reviewed By: xazax.hun, martong
Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D56441
llvm-svn: 350852
Current testing setup for analyzer tests with Z3 is rather inconvenient:
There's no way to run the analyzer tests separately (I use
LIT_FILTER=Analysis ninja check-clang, but a direct target is nicer).
When Clang is built with Z3 support, there's no way to *not* run tests
with Z3 solver, and this is often desired, as tests with Z3 solver take
a very long time.
This patch introduces two extra targets:
- check-clang-analyzer
- check-clang-analyzer-z3
which solve those problems.
Differential Revision: https://reviews.llvm.org/D50594
llvm-svn: 339629
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Thanks to Stella Stamenova for helping make this work on Windows.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335295
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335177
Summary:
TypeID summaries are used by CFI and need to be serialized by ThinLTO
indexing for later use by LTO Backend.
Reviewers: tejohnson, pcc
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D42611
llvm-svn: 325182
Summary:
The new version of debuginfo-tests will have it's own
lit.cfg.py file which is incompatible with the one in clang/test.
This change supports both the old and new versions, and can be used
until the bots actually move debuginfo-tests to either clang/test or
the monorepo.
This is a prerequisite for D40971.
Reviewers: zturner, aprantl
Subscribers: mgorny, JDevlieghere, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D41055
llvm-svn: 320494
This is still breaking greendragon.
At this point I give up until someone can fix the greendragon
bots, and I will probably abandon this effort in favor of using
a private github repository.
llvm-svn: 318722
This was reverted due to the tests being run twice on some
build bots. Each run had a slightly different configuration
due to the way in which it was being invoked. This fixes
the problem (albeit in a somewhat hacky way). Hopefully in
the future we can get rid of the workflow of running
debuginfo-tests as part of clang, and then this hack can
go away.
llvm-svn: 318697
This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.
You can observe this by running:
ninja -nv check-all | grep debuginfo-tests
And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice. The fix is
going to involve either:
a) figuring out that we're running in this "deprecated" configuration,
and then deleting the clang/test/debuginfo-tests path, which should
cause it to behave identically to before, or:
b) make lit smart enough that it doesn't descend into a sub-suite if
that sub-suite already has a lit.cfg file.
llvm-svn: 318486
This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable. We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.
llvm-svn: 318435
This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.
llvm-svn: 318112
This patch introduces a class that can help to build tools that require cross
translation unit facilities. This class allows function definitions to be loaded
from external AST files based on an index. In order to use this functionality an
index is required. The index format is a flat text file but it might be
replaced with a different solution in the near future. USRs are used as names to
look up the functions definitions. This class also does caching to avoid
redundant loading of AST files.
Right now only function defnitions can be loaded using this API because this is
what the in progress cross translation unit feature of the Static Analyzer
requires. In to future this might be extended to classes, types etc.
Differential Revision: https://reviews.llvm.org/D34512
llvm-svn: 313975
This follows in line with a previous patch of renaming LLVM's.
Working on these files is difficult in certain operating systems
and/or environments that don't like handling python code with a
non .py file extension.
llvm-svn: 313892
local-rename action
This commit introduces the clang-refactor tool alongside the local-rename action
which uses the existing renaming engine used by clang-rename. The tool
doesn't actually perform the source transformations yet, it just provides
testing support. This commit also moves only one test from clang-rename over to
test/Refactor. I will continue to move the other tests throughout
development of clang-refactor.
The following options are supported by clang-refactor:
-v: use verbose output
-selection: The source range that corresponds to the portion of the source
that's selected (currently only special command test:<file> is supported).
Please note that a follow-up commit will migrate clang-refactor to
libTooling's common option parser, so clang-refactor will be able to use
the common interface with compilation database and options like -p, -extra-arg,
etc.
The testing support provided by clang-refactor is described below:
When -selection=test:<file> is given, clang-refactor will parse the selection
commands from that file. The selection commands are grouped and the specified
refactoring action invoked by the tool. Each command in a group is expected to
produce an identical result. The precise syntax for the selection commands is
described in a comment in TestSupport.h.
Differential Revision: https://reviews.llvm.org/D36574
llvm-svn: 313244
Use the new llvm_canonicalize_cmake_booleans() function to canonicalize
booleans for lit tests. Replace the duplicate ENABLE_CLANG* variables
used to hold canonicalized values with in-place canonicalization. Use
implicit logic in Python code to avoid overrelying on exact 0/1 values.
Differential Revision: https://reviews.llvm.org/D28529
llvm-svn: 293052
Summary:
This reverts commit r292662.
This change broke internal builds. Will provide a reproducer internally.
Subscribers: pcc, mehdi_amini, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29025
llvm-svn: 292791
Recommitted after formal approval.
LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project.
Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault.
Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code.
I propose that the parts required to build a simple expression parser be added to Clang. Initially, I aim to have the following features:
A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests.
A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside.
This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter. When complete, this tester will implement the first of the above goals.
Differential Revision: https://reviews.llvm.org/D27180
llvm-svn: 290367