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

[Dávid Bolvanský via Phabricator via llvm-commits]

xbolva00 marked an inline comment as done.
xbolva00 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>;
----------------
Quuxplusone wrote:
> 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`).
I am also wondering if we could use some better term than "control paths", but I haven't found any :)  Paths sound to general for me but I am not strongly opposed.

if @aaron.ballman  is happy with your wording, so do I.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69762/new/

https://reviews.llvm.org/D69762