| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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
|
|
|
|
|
|
| |
statement.
llvm-svn: 76583
|
|
|
|
|
|
| |
an incremental patch
llvm-svn: 75622
|
|
|
|
| |
llvm-svn: 74086
|
|
|
|
| |
llvm-svn: 73101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
disabled but are used anyway
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
|
|
|
|
|
|
| |
pointed out by Doug.
llvm-svn: 62944
|
|
|
|
| |
llvm-svn: 61821
|
|
|
|
|
|
|
|
| |
__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
|
|
|
|
|
|
|
|
| |
Parser side.
No Sema functionality change, just the signatures of the Action/Sema methods.
llvm-svn: 58913
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 57746
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
parentheses, e.g.:
sizeof(int()) -> "int()" is type-id
sizeof(int()+1) -> "int()+1" is expression.
llvm-svn: 57131
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|