[clang] [Liveness][analyzer] Fix liveness of binary logical operators and their subexpressions (PR #231419)

[Donát Nagy via cfe-commits]

================
@@ -339,6 +339,15 @@ void TransferFunctions::Visit(Stmt *S) {
       AddLiveExpr(val.liveExprs, LV.ESetFact, CO->getFalseExpr());
       return;
     }
+    case Stmt::BinaryOperatorClass: {
+      auto const *BO = cast<BinaryOperator>(S);
+      if (BO->isLogicalOp()) {
----------------
NagyDonat wrote:

Very good point, although probably out of scope for this particular change, because this change does not have a significant effect on the handling of these strongly short-circuited expressions.

When we `Visit` the expression `true || b` or `false && a`, its non-const operand was already marked as live before this change, because the default behavior is that we mark all children of the statement as live. There might be some logic that makes these dead sub-expressions completely inaccessible for liveness, but I doubt that there is.

This commit only changes that in the combination of multiple short-circuiting operators (e.g. `(b && b) || (b && b)` or a case like `(false && a) || b` that involves a short-circuiting literal) visiting the top-level operator puts liveness not only on its immediate children, but also on some deeper sub-expressions. (The sub-expressions that are accessible through only short-circuiting operators, e.g. visiting the `||` in `((a && b) == c) || d` wouldn't mark `a` or `b` live because the recursion doesn't descend into the `==`.) Here the only change is that the new code adds a liveness a bit earlier in the backward sweep (i.e. the operand would remain live a bit longer during the symbolic execution), but it's unchanged that it is marked as live at some point.

(By the way this is mostly irrelevant for the path-sensitive analysis, because we won't enter the CFGBlock that is "cut off" by the short-circuiting literal, so the liveness of its sub-expression does not influence anything. Perhaps it could influence things like leak reports? :thinking: )

I'm open to discussing this if you're interested, but in that case we should probably move this discussion elsewhere.

https://github.com/llvm/llvm-project/pull/231419