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).
I belive many of these diagnostics changed from errors to warnings in
r357394. I've simply mechanically updated the tests, but whoever owns
this code should probably audit for unintented behavior changes. I
wasn't able to find a flag to make these warnings errors again.
llvm-svn: 360701
I think there must be a bug in git-llvm causing parent directories to be
deleted when the diff deletes files in a subdirectory. Perhaps it is
Windows-only.
There has been a behavior change, so some of these tests now fail. I
have marked them XFAIL and will fix them in a follow-up to separate the
changes.
llvm-svn: 360699
As outlined in a previous RFC, the test/ASTMerge/Inputs folder is getting full and the tests are starting to become interdependent. This is undesirable because
- it makes it harder to write new tests
- it makes it harder to figure out at a glance what old tests are doing, and
- it adds the risk of breaking one test while changing a different one, because of the interdependencies.
To fix this, according to the conversation in the RFC, I have changed the layout from
a.c
Inputs/a1.c
Inputs/a2.c
to
a/test.c
a/Inputs/a1.c
a/Inputs/a2.c
for all existing tests. I have also eliminated interdependencies by replicating the input files for each test that uses them.
https://reviews.llvm.org/D26571
llvm-svn: 287129
