| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
fields to two 16-bit values instead of using bitfields.
llvm-svn: 101020
|
| |
|
|
|
|
| |
type, instead of having sema do it.
llvm-svn: 101016
|
| |
|
|
| |
llvm-svn: 101006
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LookupInObjCMethod. Doing so allows all sorts of invalid code
to slip through to codegen. This patch does not change the
AST representation of super, though that would now be a natural
thing to do since it can only be in the receiver position and
in the base of a ObjCPropertyRefExpr.
There are still several ugly areas handling super in the parser,
but this is definitely a step in the right direction.
llvm-svn: 100959
|
| |
|
|
|
|
|
|
|
|
| |
when they're instantiated. Merge the note into the -Wreorder warning; it
doesn't really contribute much, and it was splitting a thought across diagnostics
anyway. Don't crash in the parser when a constructor's initializers end in a
comma and there's no body; the recovery here is still terrible, but anything's
better than a crash.
llvm-svn: 100922
|
| |
|
|
|
|
|
| |
Declarator that depends on it. This fixes several redundant errors and bad
recoveries.
llvm-svn: 100779
|
| |
|
|
|
|
| |
methods. wip.
llvm-svn: 100734
|
| |
|
|
|
|
| |
isNotEmpty calls.
llvm-svn: 100722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definitions, e.g., after
-
or
- (id)
we'll find all of the "likely" instance methods that one would want to
declare or define at this point. In the latter case, we only produce
results whose return types match "id".
llvm-svn: 100587
|
| |
|
|
|
|
| |
declared in categories.
llvm-svn: 100577
|
| |
|
|
|
|
| |
e.g., the right-hand side of binary expressions.
llvm-svn: 100526
|
| |
|
|
|
|
| |
returned by SetTypeSpecType.
llvm-svn: 100443
|
| |
|
|
|
|
| |
when parsing. Fixes radar 7822196.
llvm-svn: 100248
|
| |
|
|
|
|
| |
ares are not separated by ':' (radar 7030268).
llvm-svn: 100040
|
| |
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
| |
|
|
| |
llvm-svn: 100018
|
| |
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
| |
|
|
| |
llvm-svn: 99973
|
| |
|
|
| |
llvm-svn: 99972
|
| |
|
|
|
|
|
|
|
|
|
|
| |
may be tokens left in the token stream
that will interfere (they will be parsed as if they are after the class' '}') and a crash will occur because
the CachedTokens that holds them will be deleted while the lexer is still using them.
Make sure that the tokens of default args are removed from the token stream.
Fixes PR6647.
llvm-svn: 99939
|
| |
|
|
|
|
| |
end of a struct/class/union in C++, from Justin Bogner!
llvm-svn: 99811
|
| |
|
|
|
|
| |
Will fix correctly now that I have a testcase
llvm-svn: 99207
|
| |
|
|
|
|
| |
implementations (radar 7547942).
llvm-svn: 99198
|
| |
|
|
|
|
|
|
| |
ranges as part of the ASTContext. This code is not and was never used,
but contributes ~250k to the size of the Cocoa.h precompiled
header.
llvm-svn: 99007
|
| |
|
|
|
|
| |
Fixes the crash-on-invalid in PR6629.
llvm-svn: 98698
|
| |
|
|
|
|
| |
recovery for those that need it.
llvm-svn: 98689
|
| |
|
|
|
|
| |
building mainline GCC, PR6542
llvm-svn: 98661
|
| |
|
|
| |
llvm-svn: 98655
|
| |
|
|
|
|
| |
<rdar://problem/7735566>.
llvm-svn: 98613
|
| |
|
|
| |
llvm-svn: 98436
|
| |
|
|
|
| |
Tested: make CPPFLAGS=-m64 CXXFLAGS=-m64 -j8 && (cd tools/clang;make test)
llvm-svn: 98399
|
| |
|
|
|
|
| |
careful about value-dependent enumerators. Fixes PR5786.
llvm-svn: 97570
|
| |
|
|
|
|
|
|
|
|
|
| |
for the purposes of parsing default arguments. In effect, we would
re-introduce the parameter with a default argument N times (where N is
the number of parameters preceding the parameter with a default
argument). This showed up when a defaulted parameter of a member
function of a local class shadowed a parameter of the enclosing
function. Fixes PR6383.
llvm-svn: 97534
|
| |
|
|
| |
llvm-svn: 97528
|
| |
|
|
|
|
|
|
| |
*not* entering the context of the nested-name-specifier. This was
causing us to look into an uninstantiated template that we shouldn't
look into. Fixes PR6376.
llvm-svn: 97524
|
| |
|
|
| |
llvm-svn: 97519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along with a stack
of block scopes. However, this lead to funky behavior with nested
functions, e.g., in the member functions of local classes.
The explicit-stack approach is far cleaner, and we retain a 1-element
cache so that we're not malloc/free'ing every time we enter a
function. Fixes PR6382.
Also, tweaked the unused-variable warning suppression logic to look at
errors within a given Scope rather than within a given function. The
prior code wasn't looking at the right number-of-errors count when
dealing with blocks, since the block's count would be deallocated
before we got to ActOnPopScope. This approach works with nested
blocks/functions, and gives tighter error recovery.
llvm-svn: 97518
|
| |
|
|
|
|
|
|
|
| |
template definition. Do this both by being more tolerant of errors in
our asserts and by not dropping a variable declaration completely when
its initializer is ill-formed. Fixes the crash-on-invalid in PR6375,
but not the original issue.
llvm-svn: 97463
|
| |
|
|
|
|
|
|
|
| |
signal an error. This can happen even when the current token is '::' if
this is a ::new or ::delete expression.
This was an oversight in my recent parser refactor; fixes PR 5825.
llvm-svn: 97462
|
| |
|
|
| |
llvm-svn: 97405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an *almost* always incorrect case. This only does the lookahead
in the insanely unlikely case, so it shouldn't impact performance.
On this testcase:
struct foo {
}
typedef int x;
Before:
t.c:3:9: error: cannot combine with previous 'struct' declaration specifier
typedef int x;
^
After:
t.c:2:2: error: expected ';' after struct
}
^
;
llvm-svn: 97403
|
| |
|
|
|
|
| |
returns a StringRef. Use it to simplify some repetitive code.
llvm-svn: 97322
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
|
| |
|
|
|
|
|
|
| |
type-specifier-seq. Fixes some conditional-jump-on-unitialized-value
errors in valgrind. Also counts as attempt #2 at making the MSVC
buildbot happy.
llvm-svn: 97077
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...
Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier).
llvm-svn: 97058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
llvm-svn: 97045
|
| |
|
|
|
|
| |
llvm-gcc does, but are more strict on what uses of weakref we accept.
llvm-svn: 96992
|
| |
|
|
| |
llvm-svn: 96941
|
| |
|
|
| |
llvm-svn: 96819
|