Age | Commit message (Collapse) | Author |
|
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
trySkippingFunctionBodyForCodeCompletion and check isCodeCompletionEnabled() before doing the call.
Suggestions by Chris.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122792 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on array and function declarators. This is pretty far from complete, and I'll
revisit it later if someone doesn't beat me to it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122535 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implicitly atomic under -Wimplicit-atomic-properties
flag. // rdar://8774580
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122095 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
@synthesize foo = _foo;
keep track of the location of the ivar ("_foo"). Teach libclang to
visit the ivar as a member reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
manually managing them
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://8283484
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118629 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
does not terminate with @end.
// rdar: //7824372
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117991 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
protocol-qualified types such as id<Protocol>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declarations. Fixes PR8169.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115411 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
from certain GCC's. Patch by Neil Vachharajani!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113968 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the end of a statement. Fixes <rdar://problem/6896493>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Per Chris's comment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
c++ operator token. (radar 8328250).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operators (and, or, etc.) to be used as selectors
to match g++'s behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112935 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112307 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
M-x query-replace-regexp
\(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111903 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111901 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
keywords "in", "out", "inout", "byref", "bycopy", and "oneway".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111818 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warning flag in clang. Little more to do
for a PCH issue. Radar 6507158.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109129 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107933 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107929 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107491 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
precise. Fixes PR7336.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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 ']'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105221 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
message. This completion gives better results than just using the
"expression" completion, which is effectively what happened before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104895 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104585 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of properties which are of C++ objects. Code Gen to follow
(Radar 7468090).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103123 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on a method declaration (radar 7822196).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102221 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102031 91177308-0d34-0410-b5e6-96231b3b80d8
|