These will work as AST Text node dumpers, as usual, instead of AST
printers.
Note that for now, the TemplateName dumper is using the TemplateArgument
dumper through an implicit conversion.
This can be fixed in a later pass.
The ability to dump AST nodes is important to ad-hoc debugging, and
the fact this doesn't work with TypeLoc nodes is an obvious missing
feature in e.g. clang-query (`set output dump` simply does nothing).
Having TypeLoc::dump(), and enabling DynTypedNode::dump() for such nodes
seems like a clear win.
It looks like this:
```
int main(int argc, char **argv);
FunctionProtoTypeLoc <test.cc:3:1, col:31> 'int (int, char **)' cdecl
|-ParmVarDecl 0x30071a8 <col:10, col:14> col:14 argc 'int'
| `-BuiltinTypeLoc <col:10> 'int'
|-ParmVarDecl 0x3007250 <col:20, col:27> col:27 argv 'char **'
| `-PointerTypeLoc <col:20, col:26> 'char **'
| `-PointerTypeLoc <col:20, col:25> 'char *'
| `-BuiltinTypeLoc <col:20> 'char'
`-BuiltinTypeLoc <col:1> 'int'
```
It dumps the lexically nested tree of type locs.
This often looks similar to how types are dumped, but unlike types
we don't look at desugaring e.g. typedefs, as their underlying types
are not lexically spelled here.
---
Less clear is exactly when to include these nodes in existing text AST
dumps rooted at (TranslationUnit)Decls.
These already omit supported nodes sometimes, e.g. NestedNameSpecifiers
are often mentioned but not recursively dumped.
TypeLocs are a more extreme case: they're ~always more verbose
than the current AST dump.
So this patch punts on that, TypeLocs are only ever printed recursively
as part of a TypeLoc::dump() call.
It would also be nice to be able to invoke `clang` to dump a typeloc
somehow, like `clang -cc1 -ast-dump`. But I don't know exactly what the
best verison of that is, so this patch doesn't do it.
---
There are similar (less critical!) nodes: TemplateArgumentLoc etc,
these also don't have dump() functions today and are obvious extensions.
I suspect that we should add these, and Loc nodes should dump each other
(e.g. the ElaboratedTypeLoc `vector<int>::iterator` should dump
the NestedNameSpecifierLoc `vector<int>::`, which dumps the
TemplateSpecializationTypeLoc `vector<int>::` etc).
Maybe this generalizes further to a "full syntactic dump" mode, where
even Decls and Stmts would print the TypeLocs they lexically contain.
But this may be more complex than useful.
---
While here, ConceptReference JSON dumping must be implemented. It's not
totally clear to me why this implementation wasn't required before but
is now...
The dump() is not actually included recursively in any other nodes' dump,
as this is too verbose (similar to NNS) but useful in its own right.
It's unfortunate to not have the actual tests yet, but the DynTypedNode
tests are matcher-based and adding matchers is a larger task than
DynTypedNode support (but can't be done first).
(I've got a clangd change stacked on this that uses DynTypedNode and
dump(), and both work. I'll send a change for matchers next).
Differential Revision: https://reviews.llvm.org/D159300
This change enables a declaration to be conveniently displayed within
a debugger when only a pointer to its DeclContext is available. For example,
in gdb:
(gdb) p Ctx
$1 = (const clang::DeclContext *) 0x14c1a580
(gdb) p Ctx->dumpAsDecl()
ClassTemplateSpecializationDecl 0x14c1a540 <t.cpp:1:1, line:7:1> line:2:8 struct ct
`-TemplateArgument type 'int'
`-BuiltinType 0x14bac420 'int'
$2 = void
In the event that the pointed to DeclContext is invalid (that it has an
invalid DeclKind as a result of a dangling pointer, memory corruption, etc...)
it is not possible to dump its associated declaration. In this case, the
DeclContext will be reported as invalid. For example, in gdb:
(gdb) p Ctx->dumpAsDecl()
DeclContext 0x14c1a580 <unrecognized Decl kind 127>
$3 = void
Back in the mists of time, the CXXRecordDecl for the injected-class-name was
a redecl of the outer class itself.
This got changed in 470c454a6176ef31474553e408c90f5ee630df89, but only for plain
classes: class template instantation was still detecting the injected-class-name
in the template body and marking its instantiation as a redecl.
This causes some subtle inconsistent behavior between the two, e.g.
hasDefinition() returns true for Foo<int>::Foo but false for Bar::Bar.
This is the root cause of PR51912.
Differential Revision: https://reviews.llvm.org/D112765
Summary:
IgnoreUnlessSpelledInSource mode should ignore these because they are
not written in the source. This matters for example when trying to
replace types or values which are templated. The new test in
TransformerTest.cpp in this commit demonstrates the problem.
In existing matcher code, users can write
`unless(isInTemplateInstantiation())` or `unless(isInstantiated())` (the
user must know which to use). The point of the
TK_IgnoreUnlessSpelledInSource mode is to allow the novice to avoid such
details. This patch changes the IgnoreUnlessSpelledInSource mode to
skip over implicit template instantiations.
This patch does not change the TK_AsIs mode.
Note: An obvious attempt at an alternative implementation would simply
change the shouldVisitTemplateInstantiations() in ASTMatchFinder.cpp to
return something conditional on the operational TraversalKind. That
does not work because shouldVisitTemplateInstantiations() is called
before a possible top-level traverse() matcher changes the operational
TraversalKind.
Reviewers: sammccall, aaron.ballman, gribozavr2, ymandel, klimek
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80961
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
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always non-null.
This is because we still want to be able to use the various dump() functions
in a debugger.
No functional changes intended.
Reverted in fcf4d5e4499a391dff42ea1a096f146db44147b6 since a few dump()
functions in lldb where missed.
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always
non-null. This is because we still want to be able to use the various
dump() functions in a debugger.
No functional changes intended.
Also invert the sense of the return value.
As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate name for this function.
I haven't yet changed any of the strings that are output in
ASTDumper.cpp / JSONNodeDumper.cpp / TextNodeDumper.cpp in response to
whether isHidden() is set because
a) I'm not sure whether it's actually desired to change these strings
(would appreciate feedback on this), and
b) In any case, I'd like to get this pure rename out of the way first,
without any changes to tests. Changing the strings that are output in
the various ...Dumper.cpp files will require changes to quite a few
tests, and I'd like to make those in a separate change.
Differential Revision: https://reviews.llvm.org/D81392
Reviewed By: rsmith
Summary:
This class has member APIs which are useful to clients. Make it
possible to use those APIs without adding them to dump() member
functions. Doing so does not scale. The optional arguments to dump()
should be designed to be useful in a debugging context.
Reviewers: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61835
llvm-svn: 361034
This adds the -ast-dump=json cc1 flag (in addition to -ast-dump=default, which is the default if no dump format is specified), as well as some initial AST dumping functionality and tests.
llvm-svn: 360622
Summary:
This new traverser class allows clients to re-use the traversal logic
which was previously part of ASTDumper. This means that alternative
visit logic may be implemented, such as
* Dump to alternative data formats such as JSON
* Implement AST Matcher parent/child visitation matching AST dumps
Reviewers: aaron.ballman
Subscribers: jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D57472
llvm-svn: 352989
This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper.
Contributed-by: Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D56326
llvm-svn: 352906
Summary:
Was trying to understand how complicated it would be to write
a clang-tidy `openmp-exception-escape`-ish check once D57100 lands.
Just so it happens, all the data is already there,
it is just conveniently omitted from AST dump.
Reviewers: aaron.ballman, steveire, ABataev
Reviewed By: ABataev
Subscribers: ABataev, guansong, cfe-commits
Tags: #openmp, #clang
Differential Revision: https://reviews.llvm.org/D57452
llvm-svn: 352631
Introduce a new class GenericSelectionExpr::Association which bundle together
an association expression and its TypeSourceInfo.
An iterator GenericSelectionExpr::AssociationIterator is additionally added to
make it possible to iterate over ranges of Associations. This iterator is a
kind of proxy iterator which abstract over how exactly the expressions and the
TypeSourceInfos are stored.
Differential Revision: https://reviews.llvm.org/D57106
Reviewed By: aaron.ballman
Reviewers: aaron.ballman, steveire, dblaikie, mclow.lists
llvm-svn: 352369
Summary: Only an obscure case is moved.
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56829
llvm-svn: 351637
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
These conditions are duplicated from the dumpDeclContext function called
within the if(). This is presumably an attempt to avoid calling the
function in the case it will do nothing.
That may have made sense in the past if the code was different, but it
doesn't make sense now.
llvm-svn: 351604
Summary:
Removal of the child node makes it easier to separate traversal from
output generation.
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56752
llvm-svn: 351600
Summary:
This makes it easier to separate traversal of the AST from output
generation.
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56751
llvm-svn: 351597
Output all content which is local to the FunctionDecl before traversing
to child AST nodes.
This is necessary so that all of the part which is local to the
FunctionDecl can be split into a different method.
Reviewers: aaron.ballman
Differential Revision: https://reviews.llvm.org/D55083
llvm-svn: 351269
