<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 17, 2011, at 9:36 AM, Chris Lattner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 17, 2011, at 9:29 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Feb 17, 2011 at 9:25 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
so it's the same as the other case. I thought we already had some infrastructure for disabling warnings in unreachable code?</blockquote><div><br></div><div>Only in as much as the CFG we build for a few warnings will prune provably dead code. We're not using that here, this is a type-based warning. And I have to agree with Ted that these are all time-bombs in the code, waiting for a future maintainer to create a runtime error.</div>
</div>
</blockquote></div><br><div>I'm fine with that in this case, the problem is that we have other warnings that get emitted in dead branches of ?: expressions etc, which occur due to macro expansion.</div></div></blockquote><br></div><div>This general problem could be addressed by extending Sema::DiagRuntimeBehavior() to delay its diagnostics until we know whether this code is reachable or not. Currently, this routine emits diagnostics for any potentially-evaluated context.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>