<div>On Sun Jan 05 2014 at 2:36:56 PM, Michael Bao <<a href="mailto:mike.h.bao@gmail.com">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>return_expr' warning.<br>
<br>
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?</blockquote><div><br></div><div>That sounds appropriate. That's what your original patch did, right?</div>