Also resolve a long-working FIXME in the test case I modified.

llvm-svn: 102688

propagating error conditions out of the various annotate-me-a-snowflake
routines.  Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code.  On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week.  Again.

llvm-svn: 97221

llvm-svn: 95335

llvm-svn: 91738

scope specifiers.  Fix a tentative parsing bug that came up in LLVM.
Incidentally fixes some random FIXMEs in an existing testcase.

llvm-svn: 91734

The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
 - align() - semantics believed to be conformant to n3000, except for
   redeclarations and what entities it may apply to
 - final - semantics believed to be conformant to CWG issue 817's proposed
   wording, except for redeclarations
 - noreturn - semantics believed to be conformant to n3000, except for
   redeclarations
 - carries_dependency - currently ignored (this is an optimization hint)

llvm-svn: 89543

llvm-svn: 86135

llvm-svn: 81346

their members, including member class template, member function
templates, and member classes and functions of member templates.

To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,

  template<typename X> template<typename Y>
  X Outer<X>::Inner1<Y>::foo(Y) {
    return X();
  }

we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.

Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.

llvm-svn: 80044

llvm-svn: 76583

llvm-svn: 75622

llvm-svn: 74086

llvm-svn: 73101

Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and
a paren expression without considering the context past the parentheses.

Behold:
  (T())x;  - type-id
  (T())*x; - type-id
  (T())/x; - expression
  (T());   - expression

llvm-svn: 72260

instantiation for C++ typename-specifiers such as

  typename T::type

The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,

  typename T::template apply<U, V>

Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.

Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples. 

llvm-svn: 67875

by changing blocks from being disabled in the parser to being disabled
in Sema.

llvm-svn: 67816

llvm-svn: 66661

disambiguation contexts, so that we properly parse template arguments
such as

  A<int()>

as type-ids rather than as expressions. Since this can be confusing
(especially when the template parameter is a non-type template
parameter), we try to give a friendly error message.

Almost, eliminate a redundant error message (that should have been a
note) and add some ultra-basic checks for non-type template
arguments.

llvm-svn: 64189

redundant #includes.  Patch by Anders Johnsen!

llvm-svn: 63271

.def file for each library.  This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.

Patch by Anders Johnsen!

llvm-svn: 63111

llvm-svn: 62944

llvm-svn: 61821

Fix <rdar://problem/5956221> clang ObjC rewriter: Microsoft-specific __fastcall keyword unrecognized.

This fix is C++ specific.

llvm-svn: 61816

shorter and  more accurate.  The type name might not be qualified.

llvm-svn: 61788

down into the two cases that it can possibly affect.  This avoids calls
to it that obviously can't do anything.

llvm-svn: 61651

  warning: statement was disambiguated as declaration

because it is currently firing in cases where the declaration would
not actually parse as a statement. We'd love to bring this warning
back if we can make it more accurate.

llvm-svn: 61137

llvm-svn: 59853

llvm-svn: 59510

No Sema functionality change, just the signatures of the Action/Sema methods.

llvm-svn: 58913

No functionality change.

llvm-svn: 57746

Issue a warning when there's an ambiguous function declarator (that could be a direct initializer for a variable defition).
Idea originated from here: http://thread.gmane.org/gmane.comp.gcc.devel/101524

llvm-svn: 57609

llvm-svn: 57141

No funcitonality change.

llvm-svn: 57136

sizeof(int()) -> "int()" is type-id
sizeof(int()+1) -> "int()+1" is expression.

llvm-svn: 57131

Found a subtle bug caused by an implicit enum-to-bool conversion (of the TentativeParsingResult enum).
This was the motivation of the following changes:

-'TentativeParsingResult' enum is replaced by a 'TPResult' class that basically encapsulates the enum.
-TPR_true, TPR_false, TPR_ambiguous, and TPR_error enum constants are replaced by TPResult::True(), TPResult::False(), etc. calls that return a TPResult object.
-Also fixed the subtle bug in Parser::isCXXFunctionDeclarator (caught by the above changes as a compilation error).

llvm-svn: 57125

llvm-svn: 57111

Disambiguate between a declaration or expression for the 'condition' part of a if/switch/while/for statement.

llvm-svn: 57109

llvm-svn: 57108

'ParseTentative.cpp' implements the functionality needed to resolve ambiguous C++ statements, to either a declaration or an expression, by "tentatively parsing" them.

llvm-svn: 57084