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

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 21 00:53:52 PST 2018


rjmccall added inline comments.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3783
+parameters or local variables in ARC mode. When applied to parameters, it causes
+clang to omit the implicit calls to objc_retain and objc_release on function
+entry and exit respectivly. When applied to local variables, it causes clang to
----------------
These function names should be `typeset in mono`.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3784
+clang to omit the implicit calls to objc_retain and objc_release on function
+entry and exit respectivly. When applied to local variables, it causes clang to
+omit the call to retain on variable initialization, and release when the
----------------
Typo


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3787
+variable goes out of scope. Parameters and variables annotated with this
+attribute are implicitly ``const``.
+
----------------
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.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3789
+
+This attribute is meant to be used to opt-out of the additional safety that ARC
+provides when the programmer knows that the safety isn't necessary. You can read
----------------
The hyphen is unneeded here.


================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3492
+def warn_ignored_objc_externally_retained : Warning<
+  "'objc_externally_retained' can only be applied to strong retainable "
+  "object pointer types with automatic storage">, InGroup<IgnoredAttributes>;
----------------
erik.pilkington wrote:
> rjmccall wrote:
> > erik.pilkington wrote:
> > > aaron.ballman wrote:
> > > > This wording isn't quite right -- it doesn't apply to types, it applies to variables of those types. How about: `... to local variables or parameters of strong, retainable object pointer type`? or something along those lines?
> > > Sure, that is a bit more clear.
> > I'd split this into two diagnostics:
> > - "...can only be applied to local variables and parameters of retainable type" (if the type or decl kind is wrong)
> > - "...can only be applied to variables with strong ownership" (if the qualifier is wrong)
> Sure, I guess a lot of information is crammed into this one. I coalesced the two you suggested into one with a %select.
WFM


================
Comment at: clang/lib/CodeGen/CGDecl.cpp:807
+    // that we omit the retain, and causes non-autoreleased return values to be
+    // immediatly released.
+    LLVM_FALLTHROUGH;
----------------
typo


================
Comment at: clang/lib/CodeGen/CGDecl.cpp:2334
+      // If a parameter is pseudo-strong, either because of the attribute
+      // objc_externally_retained or because its 'self' in an non-init method,
+      // then we can omit the implicit retain.
----------------
I wouldn't enumerate the cases in this comment.  You might want to enumerate them in a comment on `isARCPseudoStrong()`, though.


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

https://reviews.llvm.org/D55865





More information about the cfe-commits mailing list