Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
example is not pretty:
struct S { int arr[4]; float f; };
constexpr S s = { .arr = {1,2}, .f = 3.1415f };
// Struct fields: Array: Int: 1, Int: 2, 2 x Int: 0, Float: 3.141500e+00
With this patch this becomes:
-Struct
|-field: Array size=4
| |-elements: Int 1, Int 2
| `-filler: 2 x Int 0
`-field: Float 3.141500e+00
Additionally APValues are currently only dumped as part of visiting a
ConstantExpr. This patch also dump the value of the initializer of constexpr
variable declarations:
constexpr int foo(int a, int b) { return a + b - 42; }
constexpr int a = 1, b = 2;
constexpr int c = foo(a, b) > 0 ? foo(a, b) : foo(b, a);
// VarDecl 0x62100008aec8 <col:3, col:57> col:17 c 'const int' constexpr cinit
// |-value: Int -39
// `-ConditionalOperator 0x62100008b4d0 <col:21, col:57> 'int'
// <snip>
Do the above by moving the dump functions to TextNodeDumper which already has
the machinery to display trees. The cases APValue::LValue, APValue::MemberPointer
and APValue::AddrLabelDiff are left as they were before (unimplemented).
We try to display multiple elements on the same line if they are considered to
be "simple". This is to avoid wasting large amounts of vertical space in an
example like:
constexpr int arr[8] = {0,1,2,3,4,5,6,7};
// VarDecl 0x62100008bb78 <col:3, col:42> col:17 arr 'int const[8]' constexpr cinit
// |-value: Array size=8
// | |-elements: Int 0, Int 1, Int 2, Int 3
// | `-elements: Int 4, Int 5, Int 6, Int 7
Differential Revision: https://reviews.llvm.org/D83183
Reviewed By: aaron.ballman
Summary:
These files tend to be hand-authored, and people get very confused.
I can't think of any reason that such whitespace would be intended.
Reviewers: kadircet
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80160
That way, lit's builtin 'env' command can be used for the 'env' bit.
Also it's clearer that way that the 'not' shouldn't cover 'env'
failures.
llvm-svn: 374749
Summary:
- So far, we only recognize the host compilation with offloading and
skip the offloading part.
Reviewers: tra, yaxunl
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68660
llvm-svn: 374470
Was reverted in r363379 due to build breakage.
Thanks to Nico Weber for reverting the original and suggesting the
fix.
Please see https://reviews.llvm.org/D61697
llvm-svn: 363502
Summary:
This test fails to link shared libraries because tries to run
a copied version of clang-check to see if the mock version of libcxx
in the same directory can be loaded dynamically. Since the test is
specifically designed not to look in the default just-built lib
directory, it must be disabled when building with
BUILD_SHARED_LIBS=ON.
Currently only disabling it on Darwin and basing it on the
enable_shared flag.
Reviewed By: ilya-biryukov
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61697
llvm-svn: 363298
Pass -ccc-install-dir explicitly as the compilation database code does
not pass argv[0] to getMainExecutable(), while some systems require it
to return the correct path. Since the relevant code is apparently only
applicable to Darwin, just pass correct -ccc-install-dir to make
the tests pass on *BSD systems.
Differential Revision: https://reviews.llvm.org/D56976
llvm-svn: 351752
This test, apparently for macs, fails on Windows as lit can't emulate
the shell subprocess $(which...) correctly. Some other netbsd and linux
buildbots also fail here. Limit to macs as a temporary workaround.
llvm-svn: 351360
Summary:
This is a regression of r348365.
When clang-tools run on a file without a complation database (`clang-check /tmp/t.cc`),
we will use fixed compilation database as a fallback. However the actual compiler
path in the fallback complation command is just `clang-tool` which is
insufficient to detect the libc++ dir.
Reviewers: ilya-biryukov, EricWF
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56680
llvm-svn: 351222
Summary:
By using '..' instead of fs::parent_path.
The intention of the code was to go from 'path/to/clang/bin' to
'path/to/clang/include'. In most cases parent_path works, however it
would fail when clang is run as './clang'.
This was noticed in Chromium's bug tracker, see
https://bugs.chromium.org/p/chromium/issues/detail?id=919761
Reviewers: arphaman, thakis, EricWF
Reviewed By: arphaman, thakis
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D56446
llvm-svn: 350714
Summary:
The intention is to make the tools replaying compilations from 'compile_commands.json'
(clang-tidy, clangd, etc.) find the same standard library as the original compiler
specified in 'compile_commands.json'.
Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied
on the value of resource dir as an approximation of the compiler install dir. The new logic
uses the actual compiler install dir and is performed in the driver. This is consistent with
the C++ standard library detection on other platforms and allows to override the resource dir
in the tools using the compile_commands.json without altering the
standard library detection mechanism. The tools have to override the resource dir to make sure
they use a consistent version of the builtin headers.
There is still logic in InitHeaderSearch that attemps to add the absolute includes for the
the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend
via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too,
but it could potentially break the library detection on other systems, so we don't tackle it in this
patch to keep its scope manageable.
This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675.
The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the
driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke
the libc++ detection in clang itself, which caused LLDB tests to break.
The LLDB tests pass with new fix.
Reviewers: JDevlieghere, arphaman, EricWF
Reviewed By: arphaman
Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54630
llvm-svn: 348365
This is an updated version of the D54576, which was reverted.
Problem was that SplitDebugName calls the InputInfo::getFilename
which asserts if InputInfo given is not of type Filename:
const char *getFilename() const {
assert(isFilename() && "Invalid accessor.");
return Data.Filename;
}
At the same time at that point, it can be of type Nothing and
we need to use getBaseInput(), like original code did.
Differential revision: https://reviews.llvm.org/D55006
llvm-svn: 348352
Summary:
When they read compiler args from compile_commands.json.
This change allows to run clang-based tools, like clang-tidy or clangd,
built from head using the compile_commands.json file produced for XCode
toolchains.
On MacOS clang can find the C++ standard library relative to the
compiler installation dir.
The logic to do this was based on resource dir as an approximation of
where the compiler is installed. This broke the tools that read
'compile_commands.json' and don't ship with the compiler, as they
typically change resource dir.
To workaround this, we now use compiler install dir detected by the driver
to better mimic the behavior of the original compiler when replaying the
compilations using other tools.
Reviewers: sammccall, arphaman, EricWF
Reviewed By: sammccall
Subscribers: ioeric, christof, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54310
llvm-svn: 346652
Summary:
Compound literals, enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.
Reviewers: rsmith, shafik
Reviewed By: rsmith
Subscribers: cfe-commits, jyknight, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D53921
llvm-svn: 346455
Summary:
See the existing InterpolatingCompilationDatabase for details on how this works.
We've been using this in clangd for a while, the heuristics seem to work well.
Reviewers: bkramer
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51729
llvm-svn: 342228
This change fixes the problem in https://bugs.llvm.org/show_bug.cgi?id=38332
by allowing driver::Action::BackendJobClass to run with the analyzer.
Otherwise, such jobs will look up the non-existing compilation database
and then run without flags.
Also filter out the -Wa,* flags that could be passed to and ignored
by the clang compiler. Clang-tidy gives warnings about unused -Wa,* flags.
Differential Revision: http://reviews.llvm.org/D51002
llvm-svn: 340421
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This is a companion change to: https://reviews.llvm.org/D50206
Reviewers: asmith, zturner
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50281
llvm-svn: 339074
Summary:
This test would fail if the python path had spaces. Add a quote around the path to fix this problem and update some test values changed by the addition of quotes around the path.
Tested on Windows and Linux with Python 3.x
Reviewers: zturner, llvm-commits
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43164
llvm-svn: 324824
Summary:
This is an alternative to JSONCompilationDatabase for simple projects that
don't use a build system such as CMake.
(You can also drop one in ~, to make your tools use e.g. C++11 by default)
There's no facility for varying flags per-source-file or per-machine.
Possibly this could be accommodated backwards-compatibly using cpp, but even if
not the simplicity seems worthwhile for the cases that are addressed.
Tested with clangd, works great! (requires clangd restart)
Reviewers: klimek
Subscribers: ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D39799
llvm-svn: 317777
Summary:
Rename stop-after to stop-diff-after. When building LLVM with
-DLLVM_BUILD_LLVM_DYLIB=ON, stop-after collides with the stop-after
already present in LLVM.
Reviewers: johannes, arphaman
Subscribers: klimek, aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D36989
llvm-svn: 311476
Summary:
If a node referring to a name is within a class or namespace, do not use
the full qualified name, but strip the namespace prefix.
Reviewers: arphaman, bkramer
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36681
llvm-svn: 311433
Summary:
Add separate tests for the top-down and the bottom-up phase, as well as
one for the optimal matching.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36185
llvm-svn: 311284
Summary:
Ignore macros and implicit AST nodes, as well as anything outside of the
main source file.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36184
llvm-svn: 311280
clang/test/Tooling/clang-diff-ast.cpp:45:12: error: expected string not found in input
// CHECK: CXXConstructorDecl: X(void (char, int))
^
<stdin>:43:25: note: scanning from here
AccessSpecDecl: public(42)
^
<stdin>:44:2: note: possible intended match here
CXXConstructorDecl: X(void (char, int) __attribute__((thiscall)))(43)
^
llvm-svn: 311270
Summary:
Until we find a decent heuristic on how to choose between multiple
identical trees, there is no point in supporting multiple mappings.
This also enables matching of nodes with parents of different types,
because there are many instances where this is appropriate. For
example for and foreach statements; functions in the global or
other namespaces.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36183
llvm-svn: 311251
Summary:
This is done with -ast-dump; the JSON variant has been renamed to
-ast-dump-json.
Reviewers: arphaman
Differential Revision: https://reviews.llvm.org/D36180
llvm-svn: 311232
Bruno Ricci