PR15017: A '>' can appear after a type-specifier in a template-argument-list.
It turns out that there's no correctness bug here (because we can't have a type
definition in this location), but there w

PR15017: A '>' can appear after a type-specifier in a template-argument-list.
It turns out that there's no correctness bug here (because we can't have a type
definition in this location), but there was a diagnostic bug.

llvm-svn: 173766

show more ...

Give a more informative error message when the dot or arrow operator is used
on a type. Currently, it gives a generic "expected unqualified-id" error.
The new error message is "cannot use (dot|arrow

Give a more informative error message when the dot or arrow operator is used
on a type. Currently, it gives a generic "expected unqualified-id" error.
The new error message is "cannot use (dot|arrow) operator on a type".

llvm-svn: 173556

show more ...

Fix five more cases of tokens which can legally follow a type specifier.

llvm-svn: 172886

Fix parsing of class specifiers before '\n' 'operator'.

r159549 / r159164 regressed clang to reject

struct s {};
struct s
operator++(struct s a)
{ return a; }

This fixes the regression. Ri

Fix parsing of class specifiers before '\n' 'operator'.

r159549 / r159164 regressed clang to reject

struct s {};
struct s
operator++(struct s a)
{ return a; }

This fixes the regression. Richard, pleas check if this looks right.

llvm-svn: 172834

show more ...

PR9903: Recover from a member functon declared with the 'typedef' specifier by
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Bri

PR9903: Recover from a member functon declared with the 'typedef' specifier by
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!

llvm-svn: 168108

show more ...

Splitting the duplicated decl spec extension warning into two: one is an ExtWarn and the other a vanilla warning. This addresses PR13705, where const char const * wouldn't warn unless -pedantic was

Splitting the duplicated decl spec extension warning into two: one is an ExtWarn and the other a vanilla warning. This addresses PR13705, where const char const * wouldn't warn unless -pedantic was specified under the right conditions.

llvm-svn: 162793

show more ...

PR41111, PR5925, PR13210: Teach tentative parsing to annotate identifiers and
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant look

PR41111, PR5925, PR13210: Teach tentative parsing to annotate identifiers and
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).

This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.

llvm-svn: 162159

show more ...

Add diagnostics for comma at end of enum and for extra semicolon at namespace
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++

Add diagnostics for comma at end of enum and for extra semicolon at namespace
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.

llvm-svn: 160618

show more ...

Improve the diagnostic when a comma ends up at the end of a declarator group
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is

Improve the diagnostic when a comma ends up at the end of a declarator group
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is followed by something which can't
possibly be a declarator (or even something which might be a plausible typo for
a declarator), suggest that a semicolon was intended.

llvm-svn: 142544

show more ...

Avoid superfluous warning after an error is detcted and reported.
// rdar://9132143

llvm-svn: 129822

Emit a specific diagnostic when typedefing C++ bool, mirroring gcc.
Fixes rdar://8365458

llvm-svn: 119359

fix PR8380, a crash on invalid due to an illogical DeclSpec SourceRange being constructed.

llvm-svn: 118625

Fix a crash when parsing malformed out-of-line member function
definition. radar 8307865.

llvm-svn: 111163

Allow an asm label specifier on C++ methods, like GCC does.
Patch by David Majnemer!

llvm-svn: 105909

fix PR6782, an accept invalid. We weren't emitting the diagnostic
returned by SetTypeSpecType.

llvm-svn: 100443

Don't infinite-loop if TryAnnotateCXXScopeToken fails to annotate but doesn't
signal an error. This can happen even when the current token is '::' if
this is a ::new or ::delete expression.

This wa

Don't infinite-loop if TryAnnotateCXXScopeToken fails to annotate but doesn't
signal an error. This can happen even when the current token is '::' if
this is a ::new or ::delete expression.

This was an oversight in my recent parser refactor; fixes PR 5825.

llvm-svn: 97462

show more ...

improve diagnostics for C++ struct ; issues. Before:

t.cc:4:3: error: expected ';' at end of declaration list
int y;
^
t.cc:6:1: error: expected ';' at end of declaration list
};
^

After:

t.c

improve diagnostics for C++ struct ; issues. Before:

t.cc:4:3: error: expected ';' at end of declaration list
int y;
^
t.cc:6:1: error: expected ';' at end of declaration list
};
^

After:

t.cc:3:8: error: expected ';' at end of declaration list
int x
^
;
t.cc:5:8: error: expected ';' at end of declaration list
int z
^
;

llvm-svn: 95039

show more ...

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead o

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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

show more ...

If we enter parens, colons can become un-sacred, allowing us to emit
a better diagnostic in the second example.

llvm-svn: 91040

fix a more evil case of : / :: confusion arising in ?:.

llvm-svn: 91039

fix incorrect parsing of bitfields pointed out by Doug. I chose
to use ColonProtectionRAIIObject in the C codepath even though it
won't matter for consistency.

llvm-svn: 91037

reapply my patch for PR4451, which improves diagnostics for :: vs : confusion.
This time with a fix to bail out when in a dependent context.

llvm-svn: 90730

revert my previous patch, it is breaking something and I don't have time
to fix it ATM.

llvm-svn: 90717

implement PR4451, improving error recovery for a mistaken : where a :: was
intended. On the first testcase in the bug, we now produce:

cxx-decl.cpp:12:2: error: unexpected ':' in nested name specif

implement PR4451, improving error recovery for a mistaken : where a :: was
intended. On the first testcase in the bug, we now produce:

cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier
y:a a2;
^
::

instead of:

t.cc:8:1: error: C++ requires a type specifier for all declarations
x:a a2;
^
t.cc:8:2: error: invalid token after top level declarator
x:a a2;
^
;
t.cc:9:11: error: use of undeclared identifier 'a2'
x::a a3 = a2;
^

llvm-svn: 90713

show more ...

Fix some C++ error recovery problems in init declarator parsing
that I noticed working on other things.

Instead of emitting:

t2.cc:1:8: error: use of undeclared identifier 'g'
int x(*g);
^
t

Fix some C++ error recovery problems in init declarator parsing
that I noticed working on other things.

Instead of emitting:

t2.cc:1:8: error: use of undeclared identifier 'g'
int x(*g);
^
t2.cc:1:10: error: expected ')'
int x(*g);
^
t2.cc:1:6: note: to match this '('
int x(*g);
^

We now only emit:

t2.cc:1:7: warning: type specifier missing, defaults to 'int'
int x(*g);
^


Note that the example in SemaCXX/nested-name-spec.cpp:f4 is still
not great, we now produce both of:

void f4(undef::C); // expected-error {{use of undeclared identifier 'undef'}} \
expected-error {{variable has incomplete type 'void'}}

The second diagnostic should be silenced by something getting marked invalid.
I don't plan to fix this though.

llvm-svn: 68919

show more ...