[PATCH] D69762: [Diagnostics] Try to improve warning message for -Wreturn-type
Arthur O'Dwyer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 7 12:41:18 PST 2019
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
More information about the llvm-commits
mailing list