================ @@ -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:
Writing an RFC on the [forums](https://discourse.llvm.org) is a good idea, yeah. I agree that, as a "this is fine to capture because the lifetime is longer than you think" suppression mechanism, an attribute on the block seems too broad. It's unfortunate that putting attributes on the captured variables makes `this` really awkward, though. I don't have a good suggestion for that, only the not-great suggestion of allowing the declaration-specific attribute to also be written on the block with a list of captures to not warn about. If blocks could have explicit capture lists, putting an attribute on a capture list item would be a very appealing solution, but alas. Regardless, we should probably allow `__attribute__((noescape))` on the block as an "all these captures are fine because I promise this block doesn't outlive its scope" suppression mechanism. 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
