[PATCH] D55865: [ObjC] Add a new attribute to opt-out of implicit callee retain/release in ARC

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added inline comments.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3787
+variable goes out of scope. Parameters and variables annotated with this
+attribute are implicitly ``const``.
+
----------------
rjmccall wrote:
> You should add a paragraph contrasting this with ``__unsafe_unretained``.  For example:
> 
>   Unlike an `__unsafe_unretained` variable, an externally-retained variable remains
>   semantically `__strong`.  This affects features like block capture which copy the
>   current value of the variable into a capture field of the same type: the block's
>   capture field will still be `__strong`, and so the value will be retained as part of
>   capturing it and released when the block is destroyed.  It also affects C++ features
>   such as lambda capture, `decltype`, and template argument deduction.
> 
> You should also describe this attribute in AutomaticReferenceCounting.rst.
> You can add it in a new `arc.misc.externally_retained` section immediately above
> `arc.misc.self`.  You can borrow some of the existing wording from the two
> following sections, `arc.misc.self` and `arc.misc.enumeration`, and then make
> those sections refer back to the new concept.
Sure, I pretty much just copied that in verbatim. New patch updates ARC.rst as well.


================
Comment at: clang/test/SemaObjC/externally-retained.m:14
+
+  EXT_RET int (^d)() = ^{return 0;};
+  EXT_RET ObjCTy *e = 0;
----------------
aaron.ballman wrote:
> erik.pilkington wrote:
> > aaron.ballman wrote:
> > > Should this be useful for function pointer parameters as well? e.g.,
> > > ```
> > > typedef void (*fp)(EXT_RET __strong ObjCTy *);
> > > 
> > > void f(__strong ObjCTy *);
> > > 
> > > void g(EXT_RET ObjCTy *Ptr) {
> > >   fp Fn = f; // Good idea? Bad idea?
> > >   Fn(Ptr); // Which behavior "wins" in this call?
> > > }
> > > ```
> > The attribute doesn't have any effect on the caller side, so when used with a function pointer type the attribute doesn't really do anything (the function definition always "wins").
> Perhaps we should warn (and drop the attribute) if you try to write it on a parameter in a function pointer type rather than a function declaration? That way users won't think code like the above does anything useful. Alternatively, we could warn if there was a mismatch between markings (so the attribute is still a noop with function pointer types, but the consistent markings make that benign).
In the new patch, applying the attribute to a parameter in a function pointer type is impossible.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55865/new/

https://reviews.llvm.org/D55865