it as used. Otherwise, we can fail to instantiate or validate the destructor,
which can lead to crashes in IR gen like PR10351.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135073 91177308-0d34-0410-b5e6-96231b3b80d8
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135051 91177308-0d34-0410-b5e6-96231b3b80d8
Make it also available in ObjC++ propeties. Use common code for
objc and objc++ so they don't diverge. // rdar://9740328
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135050 91177308-0d34-0410-b5e6-96231b3b80d8
i32. They almost always end up this way in the end anyway, and if we get
lucky, this avoids generating some bitcasts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135032 91177308-0d34-0410-b5e6-96231b3b80d8
unrestricted unions, which ended up attempting to initialize objects
in a union (which CodeGen isn't prepared for). Fixes PR9683.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135027 91177308-0d34-0410-b5e6-96231b3b80d8
the complete destructor and then invoke the global delete
operator. Previously, we would invoke the deleting destructor, which
calls the wrong delete operator. Fixes PR10341.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135021 91177308-0d34-0410-b5e6-96231b3b80d8
block pointers) that don't have any qualification to be POD types. We
were previously considering them to be non-POD types, because this was
convenient in C++ for is_pod-like traits. However, we now end up
inferring lifetime in such cases (template arguments infer __strong),
so it is not necessary.
Moreover, we want rvalues of object type (which have their lifetime
stripped) to be PODs to allow, e.g., va_arg(arglist, id) to function
properly. Fixes <rdar://problem/9758798>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134993 91177308-0d34-0410-b5e6-96231b3b80d8
implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134992 91177308-0d34-0410-b5e6-96231b3b80d8
dependent. This covers an odd class of types such as
int (&)[sizeof(sizeof(T() + T()))];
which involve template parameters but, because of some trick typically
involving a form of expression that is never type-dependent, resolve
down to a non-dependent type. Such types need to be mangled
essentially as they were written in the source code (involving
template parameters), rather than via their canonical type.
In general, instantiation-dependent types should be mangled as
they were written in the source. However, since we can't do that now
without non-trivial refactoring of the AST (see the new FIXME), I've
gone for this partial solution: only use the as-written-in-the-source
mangling for these strange types that are instantiation-dependent but
not dependent. This provides better compatibility with previous
incarnations of Clang and with GCC. In the future, we'd like to get
this right.
Fixes <rdar://problem/9663282>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134984 91177308-0d34-0410-b5e6-96231b3b80d8
builds introduced in r134972:
lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType'
lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument
This fixes the issue by passing CodeGenFunction on down, and using its
builder directly rather than passing just the builder down.
This may not be the best / cleanest fix, Chris please review. It at
least fixes builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134977 91177308-0d34-0410-b5e6-96231b3b80d8
It would be cool if we could do overload resolution to suggest
the right function, but at least this fixes the crashing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134976 91177308-0d34-0410-b5e6-96231b3b80d8
isSugared() and desugar() routines previously provided were never
actually called, since the corresponding types
(DependentTypeOfExprType, DependentDecltypeType) don't have
corresponding type classes. Outside of the current (incomplete) patch
I'm working on, I haven't found a way to trigger this problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134973 91177308-0d34-0410-b5e6-96231b3b80d8
uncompleted struct types. We now do what llvm-gcc does and compile
them into [i8 x 0]. If the type is later completed, we make sure that
it is appropriately cast.
We compile the terrible example to something like this now:
%struct.A = type { i32, i32, i32 }
@g = external global [0 x i8]
define void @_Z1fv() nounwind {
entry:
call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*))
ret void
}
declare void @_Z3fooP1A(%struct.A*)
define %struct.A* @_Z2f2v() nounwind {
entry:
ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1)
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134972 91177308-0d34-0410-b5e6-96231b3b80d8
stuff like this:
typedef struct {
int x, y, z;
} foo_t;
foo_t g;
into:
%"struct.<anonymous>" = type { i32, i32, i32 }
we now get:
%struct.foo_t = type { i32, i32, i32 }
This doesn't change the behavior of the compiler, but makes the IR much easier to read.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134969 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Devang Patel
Ted Kremenek
John McCall
Argyrios Kyrtzidis
Fariborz Jahanian
Chris Lattner
Eli Friedman
Richard Smith
Bruno Cardoso Lopes
David Chisnall
Peter Collingbourne
Benjamin Kramer
Jay Foad
Chandler Carruth
Hans Wennborg