| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
being constructed.
llvm-svn: 118625
|
|
|
|
|
|
|
| |
does not terminate with @end.
// rdar: //7824372
llvm-svn: 117991
|
|
|
|
| |
llvm-svn: 116569
|
|
|
|
|
|
| |
list, complain about it! Fixes PR7053.
llvm-svn: 116551
|
|
|
|
| |
llvm-svn: 116312
|
|
|
|
|
|
| |
skipped and not inserted into the AST for now.
llvm-svn: 116203
|
|
|
|
|
|
|
| |
__assume
__noop
llvm-svn: 116202
|
|
|
|
| |
llvm-svn: 115785
|
|
|
|
| |
llvm-svn: 115004
|
|
|
|
| |
llvm-svn: 114318
|
|
|
|
| |
llvm-svn: 114316
|
|
|
|
|
|
| |
for Clang side of support.
llvm-svn: 114253
|
|
|
|
| |
llvm-svn: 114251
|
|
|
|
| |
llvm-svn: 113356
|
|
|
|
|
|
| |
I, at least, make this typo all the time.
llvm-svn: 113243
|
|
|
|
|
|
| |
some issues being sorted out.
llvm-svn: 112493
|
|
|
|
| |
llvm-svn: 112460
|
|
|
|
|
|
|
|
|
|
| |
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
|
|
|
|
|
|
|
|
| |
different
behavior in C than in C++ (which is what the original test case was).
llvm-svn: 112199
|
|
|
|
|
|
| |
it might previously have been a tag TST.
llvm-svn: 112196
|
|
|
|
| |
llvm-svn: 111999
|
|
|
|
|
|
| |
definition. radar 8307865.
llvm-svn: 111163
|
|
|
|
| |
llvm-svn: 110764
|
|
|
|
| |
llvm-svn: 110609
|
|
|
|
|
|
| |
provide a test case; thanks Doug!
llvm-svn: 110603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default arguments that were part of
lexed method declarations.
This avoid interference with tokens coming after the point where the default arg tokens were 'injected', e.g. for
typedef struct Inst {
void m(int x=0);
} *InstPtr;
when parsing '0' the next token would be '*' and things would be messed up.
llvm-svn: 110436
|
|
|
|
|
|
| |
Patch by Francois Pichet!
llvm-svn: 110344
|
|
|
|
| |
llvm-svn: 110316
|
|
|
|
|
|
| |
Windows without svn:eol-style=native.
llvm-svn: 110308
|
|
|
|
|
|
| |
options align.
llvm-svn: 109952
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parenthesized, unlike in C++, e.g.,
C has: typeof ( expression)
C++ has: typeof unary-expression
So, once we've parsed a parenthesized expression after typeof, we
should only go on to parse the postfix expression suffix if we're in
C++. Fixes <rdar://problem/8237491>.
llvm-svn: 109606
|
|
|
|
|
|
|
| |
worked for C anyway. Also kills the -cc1 options -parse-noop and
-parse-print-callbacks.
llvm-svn: 109392
|
|
|
|
| |
llvm-svn: 109087
|
|
|
|
|
|
|
| |
diagnostic. Instead, put it and the "declaration does not declare
anything" warning into -Wmissing-declarations.
llvm-svn: 108527
|
|
|
|
| |
llvm-svn: 108526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
C++). Fixes PR7466.
llvm-svn: 108231
|
|
|
|
|
|
|
|
|
|
| |
In the case of backtracking, the cached token lexer will be the only
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.
This fixes PR7072.
llvm-svn: 108124
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
'expected ';' after top level declarator' which is much less vague.
llvm-svn: 108106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 107347
|
|
|
|
|
|
|
|
|
|
| |
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by David Majnemer!
llvm-svn: 105909
|
|
|
|
|
|
| |
lead to heartache. Fixes <rdar://problem/8044088>.
llvm-svn: 105178
|
|
|
|
|
|
|
| |
what we used to be doing, and makes sure that paired '#pragma options
align=reset' won't fail.
llvm-svn: 104998
|
|
|
|
|
|
|
| |
- Docs are fairly sketchy, if someone wants to pore through gcc to look for
holes I'd appreciate any failing test cases!
llvm-svn: 104809
|
|
|
|
| |
llvm-svn: 104789
|