Only enable code patterns (e.g., try { statements } catch (...) {
statements }) in the code-completion results if explicitly requested.

llvm-svn: 104637

Improve code completion in failure cases in two ways:
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.

Improve code completion in failure cases in two ways:
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

show more ...

Substantially alter the design of the Objective C type AST by introducing
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list

Substantially alter the design of the Objective C type AST by introducing
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.

Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.

By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.

llvm-svn: 103870

show more ...

Merged Elaborated and QualifiedName types.

llvm-svn: 103517

It turns out that basically every caller to RequireCompleteDeclContext
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.

llvm-svn: 10

It turns out that basically every caller to RequireCompleteDeclContext
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.

llvm-svn: 102818

show more ...

Recommit my change to how C++ does elaborated type lookups, now with
two bugfixes which fix selfhost and (hopefully) the nightly tests.

llvm-svn: 102198

Revert "C++ doesn't really use "namespaces" for different kinds of names the same", which seems to break most C++ nightly test apps.

llvm-svn: 102174

C++ doesn't really use "namespaces" for different kinds of names the same
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might im

C++ doesn't really use "namespaces" for different kinds of names the same
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.

Fixes PR 6885 as well some spectrum of unfiled bugs.

llvm-svn: 102164

show more ...

Rework the Parser-Sema interaction for Objective-C message
sends. Major changes include:

- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMe

Rework the Parser-Sema interaction for Objective-C message
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

show more ...

Overhaul the AST representation of Objective-C message send
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. T

Overhaul the AST representation of Objective-C message send
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:

1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)

Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:

1) Unchanged; the object instance is represented by an Expr*.

2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...

3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).

4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.

The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!

This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:

if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}

with a switch

switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}

There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.

llvm-svn: 101972

show more ...

Eliminate the ForceRValue parameter to Sema::AddOverloadCandidate

llvm-svn: 101494

Feed proper source-location information into Sema::LookupSingleResult,
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting

Feed proper source-location information into Sema::LookupSingleResult,
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

show more ...

Make CXXScopeSpec invalid when incomplete, and propagate that into any
Declarator that depends on it. This fixes several redundant errors and bad
recoveries.

llvm-svn: 100779

Implement code completion for Objective-C method declarations and
definitions, e.g., after

-

or

- (id)

we'll find all of the "likely" instance methods that one would want to
declare or defin

Implement code completion for Objective-C method declarations and
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

show more ...

When code completion produces an overload set as its results (e.g.,
while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that

When code completion produces an overload set as its results (e.g.,
while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.

llvm-svn: 100558

show more ...

Do not produce semicolons at the end of code-completion results

llvm-svn: 100557

Only prove macros as code-completion results when we're in a case
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".

llvm-

Only prove macros as code-completion results when we're in a case
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".

llvm-svn: 100555

show more ...

When sending a message to "id", apply some heuristics to try to narrow
down the set of code-completion results based on Objective-C
conventions.

llvm-svn: 100548

Make code-completion for Objective-C message sends to "id" work in the
presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
c

Make code-completion for Objective-C message sends to "id" work in the
presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.

llvm-svn: 100535

show more ...

Implement support for code completion of an Objective-C message send to
"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively,

Implement support for code completion of an Objective-C message send to
"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively, that we know about.

Note that this implementation does not yet work well with precompiled
headers; that's coming soon.

llvm-svn: 100528

show more ...

Extend the type printing policy to allow one to turn off the printing
of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.

llvm-svn: 100470

Remember the "found declaration" for an overload candidate, which is the
entity (if applicable) which was actually looked up. If a candidate was found
via a using declaration, this is the UsingShado

Remember the "found declaration" for an overload candidate, which is the
entity (if applicable) which was actually looked up. If a candidate was found
via a using declaration, this is the UsingShadowDecl; otherwise, if
the candidate is template specialization, this is the template; otherwise,
this is the function.

The point of this exercise is that "found declarations" are the entities
we do access control for, not their underlying declarations. Broadly speaking,
this patch fixes access control for using declarations.

There is a *lot* of redundant code calling into the overload-resolution APIs;
we really ought to clean that up.

llvm-svn: 98945

show more ...

Split C++ friend declarations into their own header/implementation file.
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If t

Split C++ friend declarations into their own header/implementation file.
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.

llvm-svn: 98249

show more ...

Keep an explicit stack of function and block scopes, each element of
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along wit

Keep an explicit stack of function and block scopes, each element of
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

show more ...

Add some spacing in the code-completion results for a return statement

llvm-svn: 96567