================
@@ -2897,6 +2897,15 @@ DEF_TRAVERSE_STMT(LambdaExpr, {
if (getDerived().shouldVisitImplicitCode()) {
// The implicit model is simple: everything else is in the lambda class.
TRY_TO(TraverseDecl(S->getLambdaClass()));
+
+ // The body is normally reached through the call operator of the closure
+ // class. If that declaration is not a definition (which happens when the
+ // closure type was merged with one from another module), visit the body
+ // through the lambda expression.
+ if (CXXMethodDecl *CallOp = S->getCallOperator();
+ CallOp && !CallOp->isThisDeclarationADefinition() &&
+ getDerived().shouldVisitLambdaBody())
+ TRY_TO_TRAVERSE_OR_ENQUEUE_STMT(S->getBody());
----------------
zyn0217 wrote:
I still don't think it's wise to tweak the default RAV without a reasonable
motivation.
UNLESS there are indeed BUGs in CFE and we HAVE to fix all the RAV uses, I
would argue that it would be safe for us to limit the blast radius for now.
Yes you kept arguing it would be no-op for most 'normal' cases, then why should
innocent clients pay checking costs that they don't need? MOST code in wild are
not module-related and not every one cares about such a clang-tidy check. You
are adding maintenance burden to RAV, and I don't understand what makes you
insist that. Did you explore the solution I talked above?
https://github.com/llvm/llvm-project/pull/237067
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
