[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

> I am not sure about assuming operator bool being correct. I think we first could think about other tricks to limit the tracking (see my idea above) and if we fail I would only add such rules as a last resort.

I think this depends greatly on the stack frame layout. I seem to be perfectly fine with not tracking the value within `foo()` in

  if (foo()) {
    ...
  }

whenever `foo()` returns a `bool`. Simply because "why else would you add a check if it always returns the same value?".

However, this heuristic breaks when the same code appears in an inlined stack frame. Because given the context, we need to prove that this check makes sense *in this context*.

I strongly suspect that all of the heuristics that you're talking about depend significantly on the surrounding call stacks. Like, i suspect it so strongly that i'm ready to admit that i've no idea what we're doing anymore, and it makes sense to take a pen and a sheet of paper and try to write down the tracking rules, and then come up with an easily editable and extensible architecture for tweaking those rules as we discover more and more of them.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62883/new/

https://reviews.llvm.org/D62883