[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I agree with Aaron, it would be nice if this had some immediate effect.  One obvious suggestion: take advantage of it in code generation.  LLVM already has a parameter attribute called "nocapture" which conveys exactly the right semantics for noescape pointers and references.  For block pointers, nocapture is a weaker statement than noescape, because noescape also restricts block copies, but it's still correct.



================
Comment at: include/clang/Basic/AttrDocs.td:120
+compiler that the block cannot escape: that is, no reference to the block
+derived from the parameter value will survive after the function returns.
+
----------------
The implementation in Sema allows normal pointers and references in addition to block pointers.  Assuming that's intended, it should be documented.

You should also document that *copies* of the block are also not allowed to escape.  That's special behavior for block pointers.


================
Comment at: include/clang/Basic/AttrDocs.td:144
+knowledge. Users are responsible for making sure parameters annotated with
+``noescape`` do not actuallly escape.
+
----------------
Typo.


================
Comment at: lib/Sema/SemaDeclAttr.cpp:1522-1523
+  QualType T = cast<ParmVarDecl>(D)->getType();
+  if (!T->isAnyPointerType() && !T->isBlockPointerType() &&
+      !T->isReferenceType() && !T->isArrayType() && !T->isMemberPointerType()) {
+    S.Diag(Attr.getLoc(), diag::warn_attribute_noescape_non_pointer) << T;
----------------
aaron.ballman wrote:
> I don't think the type checking here is correct, at least according to the documentation. For instance, you don't appear to care whether the parameter is an array of block pointers vs an array of ints. Similar for the other composite types.
A member pointer is not really like the others.  Member pointers are always global constants, like function pointers; there's no meaningful scope for them to escape from.

Also, parameters never have array type.  The type of a ParmVarDecl will be the decayed type, i.e. a pointer.

Also, you should check for an invalid decl and avoid checking the type, because that's likely a cascading failure.  Test case: make a parameter with a bad type specifier.


https://reviews.llvm.org/D32210