class extensions (nonfragile-abi2).For every class @interface and class
extension @interface, if the last ivar is a bitfield of any type,
then add an implicit `char :0` ivar to the end of that interface.
llvm-svn: 111857
argument in a for-each statement (e.g., "for (id x in <blah>)"), which
restricts the expression completions provided to Objective-C types (or
class types in C++).
llvm-svn: 111843
declarator. Here, we can only see a few things (e.g., cvr-qualifiers,
nested name specifiers) and we do not want to provide other non-macro
completions. Previously, we would end up in recovery mode and would
provide a large number of non-relevant completions.
llvm-svn: 111818
- 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
-There are 2 instances that change the TokenID for GNU libstdc++ 4.2 compatibility.
To handler those cases introduce a RevertedTokenID bitfield, RevertTokenIDToIdentifier() and hasRevertedTokenIDToIdentifier() methods.
Store the bitfield in PCH.
llvm-svn: 110868
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
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
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
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
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
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
For
void f( a:🅱️:c );
we would cache the tokens "a:🅱️:" 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:🅱️:".
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
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
"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
(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
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
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
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
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
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
if/switch/while/do/for statements. Previously, we would end up either:
(1) Forgetting to destroy temporaries created in the condition (!),
(2) Destroying the temporaries created in the condition *before*
converting the condition to a boolean value (or, in the case of a
switch statement, to an integral or enumeral value), or
(3) In a for statement, destroying the condition's temporaries at
the end of the increment expression (!).
We now destroy temporaries in conditions at the right times. This
required some tweaking of the Parse/Sema interaction, since the parser
was building full expressions too early in many places.
Fixes PR7067.
llvm-svn: 103187
ParseOptionalCXXScopeSpecifier() only annotates the subset of
template-ids which are not subject to lexical ambiguity. Add support
for the more general case in ParseUnqualifiedId() to handle cases
such as A::template B().
Also improve some diagnostic locations.
Fixes PR7030, from Alp Toker!
llvm-svn: 103081
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.
llvm-svn: 102247
arguments. Rather than having the parser call ActOnParamDeclarator
(which is a bit of a hack), call a new ActOnObjCExceptionDecl
action. We'll be moving more functionality into this handler to
perform earlier checking of @catch.
llvm-svn: 102222
statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).
llvm-svn: 102221
ConsumeAndStoreUntil would stop at tok::unknown when caching an inline method
definition while SkipUntil would go past it while parsing the method.
Fixes PR 6903.
llvm-svn: 102214
Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because
(1) The receiver of an instance message can be a qualified name such
as ::I or identity<I>::type.
(2) Expressions in C++ can start with a type.
The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.
This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,
[typename compute_receiver_type<T>::type method];
Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,
typedef typename computed_receiver_type<T>::type Computed;
[Computed method];
so this is merely a convenience.
Note also that message sends still cannot involve dependent types or
values.
llvm-svn: 102031
Objective-C class message expression into a type from the parser
(which was doing so in two places) to Action::getObjCMessageKind()
which, in the case of Sema, reduces the number of name lookups we need
to perform.
llvm-svn: 102026
sends. Major changes include:
- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.
Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in
Subversion.
llvm-svn: 102021
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
intended for redeclarations, fixing those that need it. Fixes PR6831.
This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).
llvm-svn: 101419
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
llvm-svn: 101412
super message sends in Objective-C. No actual functionality change
here, but it provides a hook so that Sema can typo-correct the
receiver in some cases.
llvm-svn: 101207
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
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
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
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
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
*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
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
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
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
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
or that's been hidden by a non-type (in C++).
The ideal C++ diagnostic here would note the hiding declaration, but this
is a good start.
llvm-svn: 96141
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
declaration, we can end up with template-id annotation tokens for
types that have not been converted into type annotation tokens. When
this is the case, translate the template-id into a type and parse as
an expression.
llvm-svn: 95404
Douglas Gregor