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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
