Based on post-commit review discussion on
2bd8493847 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 277623f4d5
Reverted in f9ad1d1c77 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 277623f4d5.
Based on post-commit review discussion on
2bd8493847 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).
We referred to all declaration in definitions in our diagnostic messages
which is can be inaccurate. Instead, classify the declaration and emit
an appropriate diagnostic for the new declaration and an appropriate
note pointing to the old one.
This fixes PR24116.
llvm-svn: 242190
We would check the type information from the declaration found by lookup
but we would neglect checking compatibility with the most recent
declaration. This would make it possible for us to not correctly
diagnose inconsistencies with declarations which were made in a
different scope.
llvm-svn: 225934
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
This is a different approach to r225780.
llvm-svn: 225875
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
typo.cpp:22:10: error: use of undeclared identifier 'radious'; did
you mean 'radius'?
return radious * pi;
^~~~~~~
radius
This was super-easy, since we already had decent recovery by looking
for names in dependent base classes.
llvm-svn: 92341
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
need them to evaluate redeclarations or call a function that hasn't
already been declared. We now keep a DenseMap of these locally-scoped
declarations so that they are not visible but can be quickly found,
e.g., when we're looking for previous declarations or before we go
ahead and implicitly declare a function that's being called. Fixes
PR3672.
llvm-svn: 65792
external declarations to also support external variable
declarations. Unified the code for these two cases into two new
subroutines.
Note that we fail to diagnose cases like the one Neil pointed
out, where a visible non-external declaration hides an external
declaration by the same name. That will require some reshuffling of
name lookup.
llvm-svn: 65385
David Blaikie