consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
In this patch, the null path releases consumed argument.
// rdar://10444474
llvm-svn: 149279
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474
llvm-svn: 149184
need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup. Using the entry block is
bad mojo.
llvm-svn: 144276
a previously-inactive cleanup, not only do we need a
flag variable, but we should also force the cleanup to
query the flag variable. However, we only need to do
this when we're activating in a context that's
conditionally executed; otherwise, we may safely
assume that the cleanup is dominated by the activation
point.
llvm-svn: 144271
full-expression. Naturally they're inactive before we enter
the block literal expression. This restores the intended
behavior that blocks belong to their enclosing scope.
There's a useful -O0 / compile-time optimization that we're
missing here with activating cleanups following straight-line
code from their inactive beginnings.
llvm-svn: 144268
block-typed __block variables using objc_retainBlock
and objc_dispose. Previously we were using
_Block_object_assign and _Block_object_destroy
with BLOCK_BYREF_CALLER, which causes the runtime
to completely ignore the retain and release.
In most cases this doesn't cause catastrophe
because the retain/release are balanced and
because the block in the variable was copied
upon assignment there. However, the stack
copy of the variable will be released when
it goes out of scope, which is a problem if
that value was released due to an assignment
to the heap copy. Similarly, a leak can occur
if the variable is assigned after the copy to
the heap.
llvm-svn: 144162
non-fragile ABI we may not be able to lay out the type and the debugger
would ignore us even if we did put in the offset. Go ahead and just
put any value there and don't look up the offset since it may not exist.
rdar://10210157
llvm-svn: 141261
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
calls, or calls to audited functions without an explicit
return attribute, to be casted without a bridge cast.
Tie this mechanism in with the existing exceptions to
the cast restrictions. State those restrictions more
correctly and generalize.
llvm-svn: 140912
This model uses the 'landingpad' instruction, which is pinned to the top of the
landing pad. (A landing pad is defined as the destination of the unwind branch
of an invoke instruction.) All of the information needed to generate the correct
exception handling metadata during code generation is encoded into the
landingpad instruction.
The new 'resume' instruction takes the place of the llvm.eh.resume intrinsic
call. It's lowered in much the same way as the intrinsic is.
llvm-svn: 140049
This is consistent with the behavior of assigning into a __strong l-value,
and it's also necessary for ensuring that the ivar doesn't end up a dangling
reference. We decided not to change the behavior of "retain" properties, but
just to make them warnings/errors when of block type.
llvm-svn: 139619
even on architectures that support unaligned access (which is the
only way this is otherwise legal, given that ivars apparently do
not honor alignment attributes).
llvm-svn: 139590
single code path. Use atomic loads and stores where necessary. Load and
store anything of the appropriate size and alignment with primitive
operations instead of going through the call.
llvm-svn: 139580
the lifetime of the block by copying it to the heap, or else we'll get
a dangling reference because the code working with the non-block-typed
object will not know it needs to copy.
There is some danger here, e.g. with assigning a block literal to an
unsafe variable, but, well, it's an unsafe variable.
llvm-svn: 139451
__block variables where the act of initialization/assignment
itself causes the __block variable to be copied to the heap
because the variable is of block type and is being assigned
a block literal which captures the variable.
rdar://problem/9814099
llvm-svn: 136337
for-in statements; specifically, make sure to close over any
temporaries or cleanups it might require. In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.
rdar://problem/9817306
llvm-svn: 136204
Introduce and document a new objc_returns_inner_pointer
attribute, and consume it by performing a retain+autorelease
on message receivers when they're not immediately loaded from
an object with precise lifetime.
llvm-svn: 135764
methods, including indirectly overridden methods like those
declared in protocols and categories. There are mismatches
that we would like to diagnose but aren't yet, but this
is fine for now.
I looked at approaches that avoided doing this lookup
unless we needed it, but the infer-related-result-type
checks were doing it anyway, so I left it with the same
fast-path check for no previous declartions of that
selector.
llvm-svn: 135743
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>.
llvm-svn: 134993
caused us to skip layout out a function accurately. If
so, flush the type cache for both the function and struct
case to ensure that any pointers to the functions get
recomputed. This is overconservative, but with this patch
clang can build itself again.
llvm-svn: 134863
conservative when converting a functiontype to IR when in a "pointer within
a struct" context. This has the unfortunate sideeffect of compiling all
function pointers inside of structs into "{}*" which, though correct, is
ugly. This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.
llvm-svn: 134861
- Emit default-initialization of arrays that were partially initialized
with initializer lists with a loop, rather than emitting the default
initializer N times;
- support destroying VLAs of non-trivial type, although this is not
yet exposed to users; and
- support the partial destruction of arrays initialized with
initializer lists when an initializer throws an exception.
llvm-svn: 134784
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
rdar://problem/9504800
llvm-svn: 134605
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
existence by always threading an edge from the catchall. Not doing
this was previously causing a crash in the very extreme case where
neither the normal cleanup nor the EH catchall was actually reachable:
we would delete the catchall entry block, which would cause us to
delete the entry block of the finally cleanup as well because the
cleanup logic would merge the blocks, which in turn triggered an assert
because later blocks in the finally would still be using values from the
entry. Laziness turns out to be the most elegant solution to the problem.
llvm-svn: 133601
__builtin___CFStringMakeConstantString and CF typed function calls
with explicit cf_returns_retained/cf_returns_not_retained attributes.
// rdar://9544832
llvm-svn: 133535
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
to be careful to emit landing pads that are always prepared to handle a
cleanup path. This is correct mostly because of the fix to the LLVM
inliner, r132200.
llvm-svn: 132209
parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.
Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.
Fixes <rdar://problem/9123036>.
llvm-svn: 132171
send if the receiver is null. Normally it's not worthwhile to check this,
but avoiding the null-initialization is nice, and this also avoids nasty
problems where the null-initialization is visible within the call because
we use an aliased result buffer. rdar://problem/9402992
llvm-svn: 131366
Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expands virtual bases as many times as they appear in the
hierarchy, clang will only expand them once at the end, to reflect the actual layout.
Note that there doesn't seem to be a way to indicate in the encoding that
packing/alignment of members is different that normal, in which case
the encoding will be out-of-sync with the real layout.
If the runtime switches to just consider the size of types without
taking into account alignment, we could easily make padding explicit in the
encoding (e.g. using arrays of chars). The encoding strings would be
longer then though.
Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.
llvm-svn: 131365
Ivar offsets for synthesized ivars are wrong, which could end up with a large
number of dirty pages because of ivar fixups at runtime. When we pack all of the
synthesized ivars into the same section, it limits the number of dirty pages
created. Place them in the "__DATA,__objc_ivar" section.
<rdar://problem/9374905>
llvm-svn: 130870
ObjC NeXt runtime where method pointer registered in
metadata belongs to an unrelated method. Ast part of this fix,
I turned at @end missing warning (for class
implementations) into an error as we can never
be sure that meta-data being generated is correct.
// rdar://9072317
llvm-svn: 130019
there is no reason to align them higher.
- This roughly matches llvm-gcc's r126913.
- It is an open question whether or not we should do this for cstring's in
general (code size vs optimization potential), for now we just match llvm-gcc
until someone wants to run some experiments.
llvm-svn: 129410
because the result is ignored. The particular example here is with
property l-values, but there could be all sorts of lovely casts that this
isn't safe for. Sink the check into the one case that seems to actually
be capable of honoring this.
llvm-svn: 129397
platform implies default visibility. To achieve these, refactor our
lookup of explicit visibility so that we search for both an explicit
VisibilityAttr and an appropriate AvailabilityAttr, favoring the
VisibilityAttr if it is present.
llvm-svn: 128336
accessed via the indirect pointer, they don't need to be pointers to pointers).
Finished moving the message lookup code into separate subclasses for each
runtime. Also performed a few smallish related tidies.
We're now bitcasting the result of the message lookup functions, rather than
casting the lookup functions themselves, so the messages.m test needed updating
to reflect this.
llvm-svn: 128180
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
The prototype for objc_msgSend() is technically variadic -
`id objc_msgSend(id, SEL, ...)`.
But all method calls should use a prototype that matches the method,
not the prototype for objc_msgSend itself().
// rdar://9048030
llvm-svn: 126754
The prototype for objc_msgSend() is technically variadic -
`id objc_msgSend(id, SEL, ...)`.
But all method calls should use a prototype that matches the method,
not the prototype for objc_msgSend itself().
// rdar://9048030
llvm-svn: 126678
_Block_object_* flags; it's just BLOCK_HAS_COPY_DISPOSE or not.
Also, we don't need to chase forwarding pointers prior to calling
_Block_object_dispose; _Block_object_dispose in fact already does
this.
rdar://problem/9006315
llvm-svn: 125823
Nobody ever gave me a clear reason for why we were doing this, and
now it's apparently causing serious problems, so if *not* having this
causes problems, we get to solve them the right way this time.
llvm-svn: 125627
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
Also, move the l-value emission code into CGObjC.cpp and teach it, for
completeness, to store away self for a super send.
Also, inline the super cases for property gets and sets and make them
use the correct result type for implicit getter/setter calls.
llvm-svn: 120887
objc_exception_rethrow, so we don't...", since something is actually trying to
call this with the wrong signature (!). Unfortunately I don't understand the new
EH infrastructure well enough to fix it immediately.
llvm-svn: 116660
both @catches and a @finally, because the second call to @objc_exception_try_enter
will clobber the exception slot. Fixes rdar://problem/8440970.
llvm-svn: 115575
information when imported variable is used
more than once. Originally though to be a bug in importing
block varibles. Fixes radar 8417746.
llvm-svn: 113675
block-literal initializer expression causes IRgen to crash.
This patch fixes by saving it in StaticLocalDecl map
already used for such purposes. (radar 8390455).
llvm-svn: 113307
using the same methods as used for normal structures.
- This fixes problems with reading past the end of the structure and with
handling straddled bit-field access.
llvm-svn: 112914
Fariborz Jahanian