| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
on array and function declarators. This is pretty far from complete, and I'll
revisit it later if someone doesn't beat me to it.
llvm-svn: 122535
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter packs (C++0x [dcl.fct]p13), including disambiguation between
unnamed function parameter packs and varargs (C++0x [dcl.fct]p14) for
cases like
void f(T...)
where T may or may not contain unexpanded parameter packs.
llvm-svn: 122520
|
|
|
|
|
|
|
|
| |
disambiguation.
Fixes rdar://8739801.
llvm-svn: 121228
|
|
|
|
|
|
|
|
|
|
| |
disambiguate between an expression (for a bit-field width) and a type
(for a fixed underlying type). Since the disambiguation can be
expensive (due to tentative parsing), we perform a simplistic
disambiguation based on one-token lookahead before going into the
full-blown tentative parsing. Based on a patch by Daniel Wallin.
llvm-svn: 120582
|
|
|
|
|
|
| |
protocol-qualified types such as id<Protocol>.
llvm-svn: 117081
|
|
|
|
|
|
| |
skipped and not inserted into the AST for now.
llvm-svn: 116203
|
|
|
|
| |
llvm-svn: 115004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sends. These are far trickier than instance messages, because we
typically have something like
NSArray alloc]
where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).
llvm-svn: 114057
|
|
|
|
|
|
|
| |
"__attribute((pascal))" or "__pascal" (and "_pascal" under
-fborland-extensions). Support still needs to be added to llvm.
llvm-svn: 112939
|
|
|
|
|
|
| |
statement header (fixes radar 8295106).
llvm-svn: 112443
|
|
|
|
|
|
|
|
|
| |
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parser is looking at a declaration or an expression, use a '=' to
conclude that we are parsing a declaration.
This is wrong. However, our previous approach of finding a comma after
the '=' is also wrong, because the ',' could be part of a
template-argument-list. So, for now we're going to use the same wrong
heuristic as GCC and Visual C++, because less real-world code is
likely to be broken this way. I've opened PR7655 to keep track of our
wrongness; note also the XFAIL'd test.
Fixes <rdar://problem/8193163>.
llvm-svn: 108459
|
|
|
|
| |
llvm-svn: 104026
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|