strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108234 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
priority as other constants. And, if we're in a place where we prefer
a pointer type, consider "nil" and "NULL" to be close matches.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107910 91177308-0d34-0410-b5e6-96231b3b80d8
bring in the entire lookup table at once.
Also, give ExternalSemaSource's vtable a home. This is important because otherwise
any reference to it will cause RTTI to be emitted, and since clang is compiled
with -fno-rtti, that RTTI will contain unresolved references (to ExternalASTSource's
RTTI). So this change makes it possible to subclass ExternalSemaSource from projects
compiled with RTTI, as long as the subclass's home is compiled with -fno-rtti.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105268 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105128 91177308-0d34-0410-b5e6-96231b3b80d8
expression context in C/Objective-C, or when we're in an
@interface/@implementation/@protocol in Objective-C(++).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104908 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103870 91177308-0d34-0410-b5e6-96231b3b80d8
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102818 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102164 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102021 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101972 91177308-0d34-0410-b5e6-96231b3b80d8
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101412 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100587 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100558 91177308-0d34-0410-b5e6-96231b3b80d8
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100555 91177308-0d34-0410-b5e6-96231b3b80d8
presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100535 91177308-0d34-0410-b5e6-96231b3b80d8
"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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100528 91177308-0d34-0410-b5e6-96231b3b80d8
of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100470 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98945 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98249 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97518 91177308-0d34-0410-b5e6-96231b3b80d8
may be some other places that could take advantage of this new information,
but I haven't really looked yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95600 91177308-0d34-0410-b5e6-96231b3b80d8
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95167 91177308-0d34-0410-b5e6-96231b3b80d8
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no longer used (yay).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93428 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor