[cfe-commits] r112335 - /cfe/trunk/test/SemaCXX/return-noreturn.cpp

[Chandler Carruth]

On Thu, Jan 6, 2011 at 7:19 PM, Chandler Carruth <chandlerc at google.com>wrote:

> Sorry to dig up an old thread...
>
> On Fri, Aug 27, 2010 at 5:19 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
>> Update test case, with comment to later investigate the correct behavior.
>>  Now the behavior is at least consistent.
>
>
> Can you explain what's going on here? As mentioned in the PR that this was
> committed with a partial fix for, these shouldn't warn. I had added some
> code to prevent the first case from warning, and left a FIXME in the code
> for the second case. I'm trying to track down what caused the first one to
> start warning again, it's causing major problems for us.
>

I think I figured this out. The change was your previous commit which
started handling ExprWithCleanups by visiting the sub-expression in the
CFGBuilder. Before that, we were able to see the ExprWithCleanups in the CFG
and AnalysisBasedWarnings.cpp had a bit of a hack to go through all of its
temporaries looking for no-return destructors. Now, we see the subexpression
in the CFG, which doesn't give us the nice iterable set of temporaries.

This causes quite a bit of trouble because we have a very large amount of
code that uses temporary objects with no-return destuctors in an analogous
way to llvm_unreachable. They are used in actual expressions, and so having
the list of temporaries was actually important. A contrived be
representative example is:

struct DeathLog {
  ~DeathLog() __attribute__((noreturn));
  DeathLog& operator <<(const char* msg) {
    (void)msg;  // Print this out...
    return *this;
  }
};

int f() {
  DeathLog() << "We died!!!";
}

Do you have ideas about how to at least let the noreturn attribute
propagate?

I tried just turning on the implicit dtor support in the CFGBuilder, since
we actually have at least some support for it now, and indeed that made all
of the warnings in this file go away, but it did very very bad things to the
unreachable code warning test, so I fear the explosion in CFG size is just
too much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110106/e2e55f54/attachment.html>