| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 109396
|
|
|
|
|
|
|
| |
worked for C anyway. Also kills the -cc1 options -parse-noop and
-parse-print-callbacks.
llvm-svn: 109392
|
|
|
|
|
|
|
| |
warning flag in clang. Little more to do
for a PCH issue. Radar 6507158.
llvm-svn: 109129
|
|
|
|
| |
llvm-svn: 109087
|
|
|
|
| |
llvm-svn: 108676
|
|
|
|
| |
llvm-svn: 108633
|
|
|
|
|
|
|
|
| |
purpose of access control. Fixes PR7644.
I can't actually find anything directly justifying this, but it seems obvious.
llvm-svn: 108521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
|
|
|
|
|
|
|
|
|
|
|
| |
IdentifierInfos.
When loading the PCH, IdentifierInfos that are associated with pragmas cause declarations that use these identifiers to be deserialized (e.g. the "clang" pragma causes the "clang" namespace to be loaded).
We can avoid this if we just use StringRefs for the pragmas.
As a bonus, since we don't have to create and pass IdentifierInfos, the pragma interfaces get a bit more simplified.
llvm-svn: 108237
|
|
|
|
|
|
|
| |
root cause of PR7481 and probably more, and has no apparent
testcases. I don't understand the logic here so I can't repair it.
llvm-svn: 108119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.
Also, avoid skipping randomly after a declaration if a
semicolon is missing. Before we'd get:
t.c:3:1: error: expected function body after function declarator
void bar();
^
Now we get:
t.c:1:11: error: invalid token after top level declarator
void foo()
^
;
llvm-svn: 108105
|
|
|
|
| |
llvm-svn: 108104
|
|
|
|
|
|
| |
declarations.
llvm-svn: 107933
|
|
|
|
|
|
|
|
|
|
|
|
| |
selector of an Objective-C method declaration, e.g., given
- (int)first:(int)x second:(int)y;
this code completion point triggers at the location of "second". It
will provide completions that fill out the method declaration for any
known method, anywhere in the translation unit.
llvm-svn: 107929
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allows Sema some limited access to the current scope, which we only
use in one way: when Sema is performing some kind of declaration that
is not directly driven by the parser (e.g., due to template
instantiatio or lazy declaration of a member), we can find the Scope
associated with a DeclContext, if that DeclContext is still in the
process of being parsed.
Use this to make the implicit declaration of special member functions
in a C++ class more "scope-less", rather than using the NULL Scope hack.
llvm-svn: 107491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters starts at the end of the template-parameter rather than at
the point where the template parameter name is encounted. For example,
given:
typedef unsigned char T;
template<typename T = T> struct X0 { };
The "T" in the default argument refers to the typedef of "unsigned
char", rather than referring to the newly-introduced template type
parameter 'T'.
Addresses <rdar://problem/8122812>.
llvm-svn: 107354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more targeted, as it simply provides toggle actions for the parser to
turn access checking on and off. We then use these to suppress access checking
only while we parse the template-id (included scope specifier) of an explicit
instantiation and explicit specialization of a class template. The
specialization behavior is an extension, as it seems likely a defect that the
standard did not exempt them as it does explicit instantiations.
This allows the very common practice of specializing trait classes to work for
private, internal types. This doesn't address instantiating or specializing
function templates, although those apparently already partially work.
The naming and style for the Action layer isn't my favorite, comments and
suggestions would be appreciated there.
llvm-svn: 106993
|
|
|
|
| |
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
|