<div dir="ltr"><br><br><div>On Sun Jan 05 2014 at 2:36:58 PM, Michael Bao <<a href="mailto:mike.h.bao@gmail.com" target="_blank">mike.h.bao@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, Jan 4, 2014 at 1:39 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
><br>
> That makes sense as to why you'd move it, but I'm still concerned<br>
> about this changing the semantics. For instance, this can now fire for<br>
> ObjCMethodDecl objects, where it used to not be possible. This could<br>
> be a bug fix, but it would also require further testing (and<br>
> confirmation from some of the ObjC experts as to whether this is<br>
> desirable).<br>
<br>
Hm, wouldn't the wrap around the diagnostic call with<br>
<br>
if (const FunctionDecl *FD = getCurFunctionDecl()) {<br>
}<br>
<br>
prevent it from firing for ObjCMethodDecl objects?<br>
<br>
But looking at the bigger picture, it seems like Joerg was more so<br>
envisioning that the warning be replaced with a better warning in the<br>
case that the 'return' statement is unreachable. However, the default<br>
behavior for the unreachable code warning is to ignore it unless<br>
-Wunreachable-code is passed into the compiler.<br>
<br>
So in the case that the 'return' statement is reachable, we definitely<br>
want to emit the 'warn_noreturn_function_has_<u></u>re<u></u>turn_expr' warning.<br></blockquote><div><br></div><div>Right - this should be a runtime diagnostic (ie: only fire on reachable code). Return is reachable so warn. This should equally fire for falling off the end of the function, of course. ( in the absence of an explicit return)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, when it isn't, I think it would be best to only emit a<br>
warning only if -Wunreachable-code is passed into the compiler. Does<br>
that sound reasonable?<br></blockquote><div><br>Sounds like the right thing to me. -Wunreachable-code still needs a lot of smarts/improvements to reduce the false-positive rate & I wouldn't want to duplicate that effort or lower the diagnostic quality in this case.<br>
<br>(the only 'out' here is if a noreturn function gives us a higher/better signal for bug finding </div></div>