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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
