[PATCH] WIP Fix for temporary destructors in conditionals

Pavel Labath labath at google.com
Tue Aug 6 08:51:47 PDT 2013

  Did you also un-revert the "support for temporary destructors" patch? Without this, the test you mentioned has to fail, because it has no way of detecting that the destructor does not return. With that patch applied, all tests pass (at least for me :) ). The patch is incomplete, and it could fail, but this will only happen for more complex expressions. To deal with that, I have tried a bit different approach. It is still based on the "saving the conditional expression value in the environment" idea, but I'll be saving it differently, not in the processBranch terminators. I'll attach that as a separate patch once i'm confident about it.

  I didn't get around to trying the trivial inlined function. I will reply to the rest of the comment after that.

  Right now, I have a different question, which is somewhat unrelated, but it is stopping me from doing large-scale tests of my changes. E.g., for code patterns like this
    const std::initializer_list<A> &a = { A(), A() };
  I end up with having destructor for 'const A [2]' in the CFG. This is then causing assertion failures all around the analyzer, since it assumes that only CXXRecordDecl's can have destructors. So, my question is: Is the presence of this element in the CFG intentional or is it a bug. I.e., should I fix the CFGBuilder to not generate the node, or change the analyzer to deal with it. Right now, I'm inclined towards the first option, as I don't see the purpose in having a destructor for the array (and i have the destructors for the contained elements in the cfg anyway), but I wanted to double check that. Do you know the answer, or should I direct it to someone else?


More information about the cfe-commits mailing list