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