Quuxplusone added inline comments.
================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:579
def warn_maybe_falloff_nonvoid_function : Warning<
- "control may reach end of non-void function">,
+ "not all control paths in this function return a value; non-void function
must return a value">,
InGroup<ReturnType>;
----------------
As long as we're messing with this wording: Does it actually help any human
reader to distinguish "control paths" versus simply "paths"? And could we DRY
it up by saying
> not all paths in this non-void {function,block} return a value
> this non-void {function,block} does not return a value
> not all paths in this coroutine return a value, and the promise type %0 does
> not declare 'return_void()'
> this coroutine does not return a value, and the promise type %0 does not
> declare 'return_void()'
I don't think the Coroutines warning needs to specifically call out "undefined
behavior," unless it is trying to say that the code is IFNDR. //Of course//
falling off the end of a function is UB if it ever actually happens at runtime;
that's no different whether it's a coroutine or a regular function/block. The
only reason for a wording difference in the Coroutines case is that the
colloquial notion of a "(non-)void coroutine" (whose return type would be
something like `task<void>`) is slightly less familiar than the colloquial
notion of a "(non-)void function" (whose return type is literally `void`).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69762/new/
https://reviews.llvm.org/D69762
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
