8 Commits

Author SHA1 Message Date
Enna1
17db3313c7
[ASTDump] TextNodeDumper learned to dump builtin name for AtomicExpr (#102748)
In 4198576157bfd0d08c08b784220d6132b709ae2c, we add support for dumping
builtin name for AtomicExpr in JSON dump. This change syncs
`TextNodeDumper` with `JSONNodeDumper`, makes `TextNodeDumper` learned
to dump builtin name for AtomicExpr.
2024-08-13 09:50:34 +08:00
David Blaikie
aee4925507 Recommit: Compress formatting of array type names (int [4] -> int[4])
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).
2021-10-21 11:34:43 -07:00
David Blaikie
f9ad1d1c77 Revert "Compress formatting of array type names (int [4] -> int[4])"
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.
2021-10-14 14:49:25 -07:00
David Blaikie
277623f4d5 Compress formatting of array type names (int [4] -> int[4])
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).
2021-10-14 14:23:32 -07:00
Bruno Ricci
cddc9993ea
[clang][test][NFC] Also test for serialization in AST dump tests, part 3/n.
The outputs between the direct ast-dump test and the ast-dump test after
deserialization should match modulo a few differences.

For hand-written tests, strip the "<undeserialized declarations>"s and
the "imported"s with sed.

For tests generated with "make-ast-dump-check.sh", regenerate the output.

Part 3/n.
2020-06-21 13:59:11 +01:00
Michael Liao
566b3164c5 [Sema] Fix the atomic expr rebuilding order.
Summary:
- Rearrange the atomic expr order to the API order when rebuilding
  atomic expr during template instantiation.

Reviewers: erichkeane

Subscribers: jfb, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67924

llvm-svn: 372640
2019-09-23 18:48:06 +00:00
Erich Keane
a957eaad00 Fix test atomic-expr.cpp after R372422
The test tried to match a path in a printout by doing '^:' which failed
on windows, since C:\... is a path.

llvm-svn: 372611
2019-09-23 14:12:13 +00:00
Erich Keane
830909b97a Ensure AtomicExpr goes through SEMA checking after TreeTransform
RebuildAtomicExpr was skipping doing semantic analysis which broke in
the cases where the expressions were not dependent. This resulted in the
ImplicitCastExpr from an array to a pointer being lost, causing a crash
in IR CodeGen.

Differential Revision: https://reviews.llvm.org/D67854

llvm-svn: 372422
2019-09-20 19:17:31 +00:00