For large floats/integers, APFloat/APInt will allocate memory from the heap to represent these numbers.
Unfortunately, when we use a BumpPtrAllocator to allocate IntegerLiteral/FloatingLiteral nodes the memory associated with
the APFloat/APInt values will never get freed.
I introduce the class 'APNumericStorage' which uses ASTContext's allocator for memory allocation and is used internally by FloatingLiteral/IntegerLiteral.
Fixes rdar://7637185
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112361 91177308-0d34-0410-b5e6-96231b3b80d8
an lvalue of another, compatible Objective-C object type (e.g., a
subclass). Introduce a new initialization sequence step kind to
describe this binding, along with a new cast kind. Fixes PR7741.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110513 91177308-0d34-0410-b5e6-96231b3b80d8
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110507 91177308-0d34-0410-b5e6-96231b3b80d8
reinterpret_casts (possibly indirectly via C-style/functional casts)
on values, e.g.,
int i;
reinterpret_cast<short&>(i);
The IR generated for this is essentially the same as for
*reinterpret_cast<short*>(&i).
Fixes PR6437, PR7593, and PR7344.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108294 91177308-0d34-0410-b5e6-96231b3b80d8
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
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107274 91177308-0d34-0410-b5e6-96231b3b80d8
provides C "integer type" semantics in C and C++ "integral type"
semantics in C++.
Note that I still need to update isIntegerType (and possibly other
predicates) using the same approach I've taken for
isIntegralType(). The two should have the same meaning, but currently
don't (!).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106074 91177308-0d34-0410-b5e6-96231b3b80d8
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106071 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
value-dependent if their initializers are value-dependent; my recent
tweak to these dependent rules overstepped by taking away this
value-dependents. Fixes a Boost.GIL regression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103476 91177308-0d34-0410-b5e6-96231b3b80d8
of the current instantiation is value-dependent. The C++ standard
fails to enumerate this case and, therefore, we missed it. Chandler
did all of the hard work of reducing the last remaining
Boost.PtrContainer failure (which had to do with static initialization
in the Serialization library) down to this simple little test.
While I'm at it, clean up the dependence rules for template arguments
that are declarations, and implement the dependence rules for template
argument packs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103464 91177308-0d34-0410-b5e6-96231b3b80d8
except it only skips implicit casts.
Also fix ObjCImplicitGetterSetterRefExpr's child_begin to skip the base expression
if it's actually a type reference (which you get with static property references).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103132 91177308-0d34-0410-b5e6-96231b3b80d8
address of an overloaded function (or function template), perform that
resolution prior to determining the implicit conversion
sequence. This resolution is not part of the implicit conversion
sequence itself.
Previously, we would always consider this resolution to be a
function pointer decay, which was a lie: there might be an explicit &
in the expression, in which case decay should not occur. This caused
the CodeGen assertion in PR6973 (where we created a
pointer to a pointer to a function when we should have had a pointer
to a function), but it's likely that there are corner cases of
overload resolution where this would have failed.
Cleaned up the code involved in determining the type that will
produced afer resolving the overloaded function reference, and added
an assertion to make sure the result is correct. Fixes PR6973.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102650 91177308-0d34-0410-b5e6-96231b3b80d8
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102542 91177308-0d34-0410-b5e6-96231b3b80d8
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102071 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
the result of comparisons are 'int' in C, it doesn't work to
test just the result type of the expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101576 91177308-0d34-0410-b5e6-96231b3b80d8
measurements of '-fsyntax-only' on combine.c (403.gcc) shows no real performance
change, but now the vector isn't leaked.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101195 91177308-0d34-0410-b5e6-96231b3b80d8
that protected members be used on objects of types which derive from the
naming class of the lookup. My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100562 91177308-0d34-0410-b5e6-96231b3b80d8
poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.
The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.
This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.
Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100196 91177308-0d34-0410-b5e6-96231b3b80d8
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99936 91177308-0d34-0410-b5e6-96231b3b80d8
dyn_cast) invocations for C++ and Objective-C types, declarations,
expressions, and statements. The statistics will be printed when
-print-stats is provided to Clang -cc1, with results such as:
277073 clang - Number of checks for C++ declaration nodes
13311 clang - Number of checks for C++ expression nodes
18 clang - Number of checks for C++ statement nodes
174182 clang - Number of checks for C++ type nodes
92300 clang - Number of checks for Objective-C declaration nodes
9800 clang - Number of checks for Objective-C expression nodes
7 clang - Number of checks for Objective-C statement nodes
65733 clang - Number of checks for Objective-C type nodes
The statistics are only gathered when NDEBUG is not defined, since
they introduce potentially-expensive operations into very low-level
routines (isa).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99912 91177308-0d34-0410-b5e6-96231b3b80d8
code when we are printing the name of an Objective-C method
whose class has not been declared. Fixes <rdar://problem/7495713>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98874 91177308-0d34-0410-b5e6-96231b3b80d8
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98149 91177308-0d34-0410-b5e6-96231b3b80d8
This was causing buildbot breakage.
This reverts commit d46e952cc8cb8d9eed8657d9a0b267910a0f745a.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96652 91177308-0d34-0410-b5e6-96231b3b80d8
to initializer expressions in an array allocated using ASTContext.
This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.
In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself. I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96642 91177308-0d34-0410-b5e6-96231b3b80d8
which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96396 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95189 91177308-0d34-0410-b5e6-96231b3b80d8
requires a temporary. Previously, we were building an initialization
sequence that bound to the bit-field as if it were a real lvalue. Note
that we previously (and still) diagnose binding of non-const
references to bit-fields, as we should.
There's no real way to test that this code is correct, since reference
binding does not *currently* have any representation in the AST. This
fix should make it easier for that to happen, so I've verified this
fix with...
Added InitializationSequence::dump(), to print an initialization
sequence for debugging purposes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94826 91177308-0d34-0410-b5e6-96231b3b80d8
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Find the
initializer anyway. Fixes PR6045.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93514 91177308-0d34-0410-b5e6-96231b3b80d8
caught several cases where we were not doing the right thing. I'm
not completely sure all cases are being handled correctly, but this should
be an improvement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92281 91177308-0d34-0410-b5e6-96231b3b80d8
- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and we don't want
to instantiate them twice.
- Rewrote the instantiation of variable initializers to cope with
non-dependent forms properly.
Together, these fix a handful of problems I introduced with the switch
to always rebuild expressions from the source code "as written."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91315 91177308-0d34-0410-b5e6-96231b3b80d8
Create a new UnresolvedMemberExpr for these lookups. Assorted hackery
around qualified member expressions; this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90161 91177308-0d34-0410-b5e6-96231b3b80d8
All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).
Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting
Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89817 91177308-0d34-0410-b5e6-96231b3b80d8
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89785 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis
John McCall
Eli Friedman
Abramo Bagnara
Douglas Gregor
Sebastian Redl
Fariborz Jahanian
Chris Lattner
Sean Hunt
Enea Zaffanella
Anders Carlsson
Zhongxing Xu
Benjamin Kramer
Ted Kremenek
Daniel Dunbar
David Chisnall
Sam Weinig
Nuno Lopes
Jeffrey Yasskin