guitard0g added inline comments.
================
Comment at: clang/include/clang/Basic/AttrDocs.td:260
+``escape`` placed on a function parameter of a pointer type is used to indicate
+that the pointer can escape the function. This means that a reference to the
object
+the pointer points to that is derived from the parameter value may survive
----------------
NoQ wrote:
> Are you sure you want "can escape" instead of "will escape"? In the former
> case it's impossible to implement the warning without false positives ("well,
> it says it may escape, but I know for sure that if I pass these other
> arguments then it won't escape"). In the latter case, of course, a lot of
> places where the value escapes conditionally won't be able to wear the
> attribute. Do I understand correctly that you want to proceed with the more
> aggressive diagnostic?
Hmm that's an interesting question. Initially my thought was that any
possibility of escaping should eliminate the option of passing in a temporary
pointer, which I think is reasonable in Swift's implicit bridging use-case. In
terms of the API contract, I was thinking that any API author who annotates
their function parameter with 'escaping' is effectively saying you shouldn't
pass in a pointer that you're not comfortable escaping. I think it may be a
little restrictive to say that the pointer will always escape for certain, but
I do think that anybody using a function that takes an escaping parameter
should treat this as if it were always escaping (if that makes sense). I
suppose my question then would be, do you think it's better to say "will
escape" if that's what the client calling into an API should expect (even
though the pointer might not always escape in the implementation)?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107026/new/
https://reviews.llvm.org/D107026
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
