On Fri, 21 Jul 2023 at 04:28, Julian Waters via Gcc <gcc@gcc.gnu.org> wrote: > > Hi all, > > I've found the places responsible for the warnings, but before I do > anything I'd like to discuss a couple of things. > > 1. What would a good name for the warning switch be? How does > -Wreturning-noreturn sound? > 2. I've thought about this for a while, and I feel like throwing a warning > for a noreturn method that isn't explicitly noreturn in the Control Flow > Graph is a little too harsh. The point of the attribute is to hint to gcc > that the method will never return even if it appears so,
Is it? My understanding is that it's for functions the compiler can't see the body of, e.g. user-defined functions similar to abort(). A function that doesn't return "even if it appears so" implies the function body is visible to the compiler. I don't think that's the primary use case. The compiler is already perfectly capable of optimizing callers appropriately if the function clearly never returns, you don't need the attribute for those cases. > and requiring that > the body explicitly do something like call abort() or loop infinitely kind > of defeats the purpose of the attribute, in my opinion I disagree, because the attribute is for the benefit of the calling code, not the function body itself. And so it still serves that purpose whatever the body of the function looks like. If you've added the attribute, so that calling code can be optimized accordingly, but then the body actually does return ... what are you playing it? That's weird and certainly deserves a warning. The calling code might not work correctly if the function does return, because it's been optimized assumed that can never happen, so you cause the program to have undefined behaviour by returning from a noreturn function. That certainly deserves a warning. The attribute's primary purpose is to inform callers the function won't return. A side effect of that is that the function itself might generate warnings if it appears to violate the contract you've made (that it won't return). To avoid those warnings, you need to write the function body so that it doesn't return. So instead of allowing the function to return, call another noreturn function (like abort), or add a __builtin_unreachable (or call std::unreachable in C++23), or throw an exception. > 3. If (2) is just me missing something, should I split the warning into 2 > different warnings for a noreturn definition with an explicit return > statement and an implicit one in the case of a method not explicitly > throwing/looping infinitely, etc? I'm not sure it's worth it, as they're closely related. Although I suppose you could have a noreturn function that must have a non-void return type in order to conform to some expected API (e.g. a virtual function, or a function who's address is taken and used as a callback), so want to disable the warning about a non-void return, but still get warnings for the function body to help you ensure it really doesn't return by mistake.
