Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c
Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)
This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.
Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
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
