| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 106668
|
| |
|
|
|
|
| |
with several tweaks by me.
llvm-svn: 106619
|
| |
|
|
|
|
|
|
|
|
|
| |
For
void f( a::b::c );
we would cache the tokens "a::b::" but then we would try to annotate them using the range "a::".
Before annotating them with the (invalid) C++ scope spec, set it to the range of "a::b::".
llvm-svn: 106536
|
| |
|
|
|
|
|
|
| |
just skip over the body of the class or class template: it's a
semantic disaster that's likely to cause invariants to break. Fixes
part of <rdar://problem/8104754>.
llvm-svn: 106496
|
| |
|
|
| |
llvm-svn: 106394
|
| |
|
|
|
|
| |
(radar 8076356) - wip.
llvm-svn: 106322
|
| |
|
|
|
|
| |
against the parser reading too few tokens.
llvm-svn: 106214
|
| |
|
|
|
|
|
|
|
|
|
| |
In a line like:
(;
the semicolon leaves Parser:ParenCount unbalanced (it's 1 even though we stopped looking for a right paren).
This may affect later parsing and result in bad recovery for parsing errors.
llvm-svn: 106213
|
| |
|
|
|
|
| |
didn't indicate violated invariants but that we weren't recovering well.
llvm-svn: 106195
|
| |
|
|
| |
llvm-svn: 106188
|
| |
|
|
|
|
|
|
| |
"previous token" location at the end of the class definition. This
eliminates a badly-placed error + Fix-It when the ';' following a
class definition is missing. Fixes <rdar://problem/8066414>.
llvm-svn: 106175
|
| |
|
|
|
|
| |
precise. Fixes PR7336.
llvm-svn: 106170
|
| |
|
|
|
|
|
|
|
|
|
| |
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.
llvm-svn: 106167
|
| |
|
|
|
|
|
|
|
| |
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.
llvm-svn: 106161
|
| |
|
|
| |
llvm-svn: 106101
|
| |
|
|
|
|
| |
Patch by David Majnemer!
llvm-svn: 105909
|
| |
|
|
|
|
| |
scattered throughout the project Makefiles.
llvm-svn: 105638
|
| |
|
|
|
|
| |
- This eliminates most dependencies on how Clang is installed relative to LLVM.
llvm-svn: 105637
|
| |
|
|
| |
llvm-svn: 105525
|
| |
|
|
|
|
| |
type-parameter within a template parameter list. Found by inspection.
llvm-svn: 105462
|
| |
|
|
|
|
| |
Andric!
llvm-svn: 105328
|
| |
|
|
|
|
|
|
|
|
|
|
| |
of isSimpleObjCMessageExpression checks the language,
so change a dynamic check into an assert.
isSimpleObjCMessageExpression is expensive, so only do it
in the common case when it is likely to matter: when the [
of the postfix expr starts on a new line. This should avoid
doing lookahead for every array expression.
llvm-svn: 105229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a simple, quick check to determine whether the expression starting
with '[' can only be an Objective-C message send. If so, don't parse
it as an array subscript expression. This improves recovery for, e.g.,
[a method1]
[a method2]
so that we now produce
t.m:10:13: error: expected ';' after expression
[a method]
^
instead of some mess about expecting ']'.
llvm-svn: 105221
|
| |
|
|
|
|
| |
lead to heartache. Fixes <rdar://problem/8044088>.
llvm-svn: 105178
|
| |
|
|
|
|
|
| |
called function itself is invalid (e.g., because of a semantic error
referring to that declaration). Fixes <rdar://problem/8044142>.
llvm-svn: 105175
|
| |
|
|
|
|
|
|
|
| |
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
llvm-svn: 105128
|
| |
|
|
|
|
| |
(radar 8040068).
llvm-svn: 105011
|
| |
|
|
| |
llvm-svn: 104990
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
llvm-svn: 104941
|
| |
|
|
|
|
|
| |
give us a decl back. Makes -cc1 -parse-noop handle a substantially larger
amount of the C++ grammar.
llvm-svn: 104940
|
| |
|
|
|
|
|
| |
completions. Plus, tweak a few completion patterns to better reflect
the language grammar.
llvm-svn: 104905
|
| |
|
|
|
|
|
| |
message. This completion gives better results than just using the
"expression" completion, which is effectively what happened before.
llvm-svn: 104895
|
| |
|
|
|
|
| |
noted, is not the same as __attribute__((packed)). That would be ridiculous!
llvm-svn: 104865
|
| |
|
|
| |
llvm-svn: 104864
|
| |
|
|
|
|
|
| |
expression, "forget" about the object type; only the
nested-name-specifier matters for name lookup purposes. Fixes PR7239.
llvm-svn: 104834
|
| |
|
|
|
|
| |
Also, fix a source location bug with the rparen in #pragma pack.
llvm-svn: 104784
|
| |
|
|
|
|
|
|
|
|
|
| |
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there are already two spaces before the token where the : was expected,
put the : in between the spaces. This means we get it right in both
of these cases:
t.c:2:17: error: expected ':'
return a ? b c;
^
:
t.c:3:16: error: expected ':'
return a ? b c;
^
:
In the later case, the diagnostic says to insert ": ", in the former
case it says to insert ":" between the spaces. This fixes rdar://8007231
llvm-svn: 104569
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
llvm-svn: 104409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
llvm-svn: 104406
|
| |
|
|
|
|
| |
Fixes <rdar://problem/7987650>.
llvm-svn: 104376
|
| |
|
|
|
|
| |
<rdar://problem/7971948>.
llvm-svn: 104291
|
| |
|
|
| |
llvm-svn: 104169
|
| |
|
|
| |
llvm-svn: 104135
|
| |
|
|
| |
llvm-svn: 104026
|
| |
|
|
|
|
| |
Fixes PR7153
llvm-svn: 103954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarator is incorrect. Not being a typename causes the parser to
dive down into the K&R identifier list handling stuff, which is almost
never the right thing to do.
Before:
r.c:3:17: error: expected ')'
void bar(intptr y);
^
r.c:3:9: note: to match this '('
void bar(intptr y);
^
r.c:3:10: error: a parameter list without types is only allowed in a function definition
void bar(intptr y);
^
After:
r.c:3:10: error: unknown type name 'intptr'; did you mean 'intptr_t'?
void bar(intptr y);
^~~~~~
intptr_t
r.c:1:13: note: 'intptr_t' declared here
typedef int intptr_t;
^
This fixes rdar://7980651 - poor recovery for bad type in the first arg of a C function
llvm-svn: 103783
|
| |
|
|
|
|
|
| |
identifier in the identifier list consumed before it is called.
No functionality change.
llvm-svn: 103781
|
| |
|
|
| |
llvm-svn: 103767
|
| |
|
|
| |
llvm-svn: 103198
|