On Sun Jan 05 2014 at 2:36:56 PM, Michael Bao <[email protected]> wrote:

> On Sat, Jan 4, 2014 at 1:39 PM, Aaron Ballman <[email protected]>
> wrote:
> >
> > That makes sense as to why you'd move it, but I'm still concerned
> > about this changing the semantics. For instance, this can now fire for
> > ObjCMethodDecl objects, where it used to not be possible. This could
> > be a bug fix, but it would also require further testing (and
> > confirmation from some of the ObjC experts as to whether this is
> > desirable).
>
> Hm, wouldn't the wrap around the diagnostic call with
>
> if (const FunctionDecl *FD = getCurFunctionDecl()) {
> }
>
> prevent it from firing for ObjCMethodDecl objects?
>
> But looking at the bigger picture, it seems like Joerg was more so
> envisioning that the warning be replaced with a better warning in the
> case that the 'return' statement is unreachable. However, the default
> behavior for the unreachable code warning is to ignore it unless
> -Wunreachable-code is passed into the compiler.
>
> So in the case that the 'return' statement is reachable, we definitely
> want to emit the 'warn_noreturn_function_has_return_expr' warning.
>
> However, when it isn't, I think it would be best to only emit a
> warning only if -Wunreachable-code is passed into the compiler. Does
> that sound reasonable?


That sounds appropriate. That's what your original patch did, right?
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to