Exactly what it says on the tin! Note that we're talking about interestingness in general, hence this isn't a control-dependency-tracking specific patch.
NoQ xazax.hun Charusso baloghadamsoftware rnkovacs dcoughlin
- rG49ac7ece163f: [analyzer] Don't make ConditionBRVisitor events prunable when the condition is…
rC369589: [analyzer] Don't make ConditionBRVisitor events prunable when the condition is…
rL369589: [analyzer] Don't make ConditionBRVisitor events prunable when the condition is…
Ugh, so this code intentionally avoids the complexity of ExprEngine::VisitCommonDeclRefExpr() so that to work differently with references. Okay.
@xazax.hun, do you think this works correctly with lambda captures? (when the DeclRefExpr to a variable might evaluate to a field within the lambda at run-time).
Decl? I guess it made sense in the original code but there's no longer an obvious Decl floating around.
Good point! This definitely worth a test case somewhere somehow!
I would expect DRE->getDecl() to return the captured declaration rather than the field and thus State->getSVal(State->getLValue(VD, LCtx)) to compute the wrong answer. I might be a bit rusty on this topic so of course we would need a carefully crafted test case to make sure :)
- Make the generic messages in-class, constexpr fields.
- Provide plenty of test cases for captured lambda variables. In our meeting we had both had a sight of relief, and some still lingering concerns about this, so maybe it deserves fixing in the long term.
So, we seem to be okay with this code in the context of this patch, but have voiced concerns that there probably is a testcase on which this doesn't work. What kind of FIXME message shall I put in before commiting?
FIXME: As seen in VisitCommonDeclRefExpr, sometimes DeclRefExpr may evaluate to a FieldRegion when it refers to a declaration of a lambda capture variable. We most likely need to duplicate that logic here.