[PATCH] D69762: [Diagnostics] Try to improve warning message for -Wreturn-type

Arthur O'Dwyer via Phabricator via cfe-commits cfe-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 cfe-commits mailing list