================ @@ -1641,6 +1641,17 @@ def warn_implicitly_retains_self : Warning < "block implicitly retains 'self'; explicitly mention 'self' to indicate " "this is intended behavior">, InGroup<DiagGroup<"implicit-retain-self">>, DefaultIgnore; +def warn_blocks_capturing_this : Warning<"block implicitly captures 'this'">, + InGroup<DiagGroup<"blocks-capturing-this">>, + DefaultIgnore; +def warn_blocks_capturing_reference + : Warning<"block implicitly captures a C++ reference">, + InGroup<DiagGroup<"blocks-capturing-reference">>, + DefaultIgnore; +def warn_blocks_capturing_raw_pointer + : Warning<"block implicitly captures a raw pointer">, ---------------- rjmccall wrote:
I don't think "raw pointer" is a term we use anywhere else in Clang diagnostics. You might say a "C pointer" or "non-Objective-C pointer". The more I think about it, though, the more I find the idea of warning about pointer captures in all escaping blocks problematic. For references, sure, I think there's a very reasonable argument that they're specifically likely to be temporary. Even for `this`, though, that really depends on the kind of programming you're doing, although I suppose there's an argument that an escaping block might need to capture a *smart* pointer to `this`. (That's definitely not reliably true, though, e.g. if someone was doing manual refcounting.) For pointers in general... unfortunately, we just can't know the ownership semantics that the user intends; I think this would be very noisy. Maybe that's okay in an opt-in warning, but it's unfortunate, because I think there's potential for the reference-capture warning to be turned on by default eventually. https://github.com/llvm/llvm-project/pull/144388 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
