This is an archive of the discontinued LLVM Phabricator instance.

[Diagnostics] Try to improve warning message for -Wreturn-type
ClosedPublic

Authored by xbolva00 on Nov 3 2019, 7:34 AM.

Diff Detail

Event Timeline

xbolva00 created this revision.Nov 3 2019, 7:34 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 3 2019, 7:34 AM
xbolva00 retitled this revision from [LegacyPassManager] Fixed "null check after derefencing" warning to [Diagnostics] Try to improve warning message for -Wreturn-type.Nov 3 2019, 7:40 AM
xbolva00 edited the summary of this revision. (Show Details)
xbolva00 added reviewers: rsmith, aaron.ballman.

I will update tests after we decide on final text.

I think the new text is more clear than the old text, so I'm fine with the current direction you're going.

clang/include/clang/Basic/DiagnosticSemaKinds.td
585–588

Should we change this wording as well? Along with any other instances of similar wording (I don't recall if we have something similar for lambdas or if we defer to the function diagnostics in that case)?

xbolva00 marked an inline comment as done.Nov 7 2019, 12:02 PM
xbolva00 added inline comments.
clang/include/clang/Basic/DiagnosticSemaKinds.td
585–588

+1, I agree.

It would be better if somebody more familiar with Obj-C / coroutines and related terminology would improve these text.

aaron.ballman added inline comments.Nov 7 2019, 12:24 PM
clang/include/clang/Basic/DiagnosticSemaKinds.td
585–588

I think you've already got the gist of it. block does not return a value; non-void blocks must return a value, and similar for coroutines.

In fact, I wonder why we don't just combine these diagnostics for all three situations and use a %select for them? That seems like a reasonable thing to do (having not put a ton of thought into it).

Quuxplusone added inline comments.
clang/include/clang/Basic/DiagnosticSemaKinds.td
580

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).

xbolva00 marked an inline comment as done.Nov 7 2019, 12:58 PM
xbolva00 added inline comments.
clang/include/clang/Basic/DiagnosticSemaKinds.td
580

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.

How about "this non-void {function|block} {may|does} not return a value"

How about "this non-void {function|block} {may|does} not return a value"

FWIW, I am happy with this clear and concise suggestion. :)

I am not sure if "may" is ideal, it could suggest that compiler is not very sure and emits just some conservative message.

"not all paths in this non-void {function,block} return a value" gives some extra confidence that compiler knows there is a buggy control path.

I'd probably go with "non-void %select{function|block|coroutine}0 does not return a value %select{|in all control paths}1"

xbolva00 added a comment.EditedNov 8 2019, 9:47 AM

We cannot use it for block; it is a hard error. Corountine and function can be merged as suggested.

Looking at Sema/AnalysisBasedWarnings.cpp, reworking it to "select" would take some time so I will prepare just simple patch without "select".

xbolva00 updated this revision to Diff 228514.EditedNov 8 2019, 1:28 PM

Fixed review comments.

aaron.ballman accepted this revision.Nov 9 2019, 5:14 AM

We cannot use it for block; it is a hard error. Corountine and function can be merged as suggested.

We can use .Text to share diagnostic text between warnings and errors (we do this elsewhere), but I don't insist for this patch.

LGTM aside from a commenting request.

clang/include/clang/Basic/DiagnosticSemaKinds.td
579

A FIXME comment that we'd like to combine these diagnostics eventually would be appreciated.

6861

And maybe move these two up closer to the other duplicate-ish diagnostics.

This revision is now accepted and ready to land.Nov 9 2019, 5:14 AM
xbolva00 marked an inline comment as done.Nov 9 2019, 7:17 AM
xbolva00 added inline comments.
clang/include/clang/Basic/DiagnosticSemaKinds.td
6861

This is in
"let CategoryName = "Lambda Issue" in {"

so I am not sure if should really move it.

aaron.ballman added inline comments.Nov 9 2019, 7:23 AM
clang/include/clang/Basic/DiagnosticSemaKinds.td
6861

I hadn't noticed that, let's leave it here. Good catch!

xbolva00 updated this revision to Diff 228578.Nov 9 2019, 8:54 AM

Added FIXME.

This revision was automatically updated to reflect the committed changes.