Objective-C declarations and statements. Fixes
<rdar://problem/8814576> (wrong source line for diagnostics about
missing ';'), and now we actually consume the ';' at the end of a
@compatibility_alias directive!
llvm-svn: 122855
classes, categories, protocols, and class extensions, where the
methods and properties of these entities would be inserted into the
DeclContext in an ordering that doesn't necessarily reflect source
order. The culprits were Sema::ActOnMethodDeclaration(), which did not
perform the insertion of the just-created method declaration into
the DeclContext for these Objective-C entities, and
Sema::ActOnAtEnd(), which inserted all method declarations at the
*end* of the DeclContext.
With this fix in hand, clean up the code-completion actions for
property setters/getters that worked around this brokenness in the AST.
Fixes <rdar://problem/8062781>, where this problem manifested as poor
token-annotation information, but this would have struck again in many
other places.
llvm-svn: 122347
protocol-qualifier list without a leading type (e.g., <#blah#>), don't
complain about it being an archaic protocol-qualifier list unless it
actually parses as one.
llvm-svn: 119805
using new/delete and OwningPtrs. After memory profiling Clang, I witnessed periodic leaks of these
objects; digging deeper into the code, it was clear that our management of these objects was a mess. The ownership rules were murky at best, and not always followed. Worse, there are plenty of error paths where we could screw up.
This patch introduces AttributeList::Factory, which is a factory class that creates AttributeList
objects and then blows them away all at once. While conceptually simple, most of the changes in
this patch just have to do with migrating over to the new interface. Most of the changes have resulted in some nice simplifications.
This new strategy currently holds on to all AttributeList objects during the lifetime of the Parser
object. This is easily tunable. If we desire to have more bound the lifetime of AttributeList
objects more precisely, we can have the AttributeList::Factory object (in Parser) push/pop its
underlying allocator as we enter/leave key methods in the Parser. This means that we get
simple memory management while still having the ability to finely control memory use if necessary.
Note that because AttributeList objects are now BumpPtrAllocated, we may reduce malloc() traffic
in many large files with attributes.
This fixes the leak reported in: <rdar://problem/8650003>
llvm-svn: 118675
Objective-C message sends. There is no functionality change here; this
is prep work for using the parameter types to help guide the
expression results when code-completing the argument.
llvm-svn: 114375
sends. These are far trickier than instance messages, because we
typically have something like
NSArray alloc]
where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).
llvm-svn: 114057
part of parser recovery. For example, given:
a method1:arg];
we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:
fixit-objc-message.m:17:3: error: missing '[' at start of message
send expression
a method1:arg];
^
[
The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.
llvm-svn: 113968
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
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
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
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
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
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
Douglas Gregor