This is an archive of the discontinued LLVM Phabricator instance.

[Failing one test] Reword [-Wreturn-type] messages to "non-void x does not return a value"
Needs ReviewPublic

Authored by easyaspi314 on Apr 13 2018, 4:10 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

Replace [-Wreturn-type] messages, "control reaches/may reach end of non-void x", to "non-void x does/might not return a value".

That warning is a very cryptic error copied from GCC, and I had to memorize the real meaning of the message in order to make sense of it.

If you were to merge this, 'Clang :: Misc/serialized-diags-stable.c' will fail.

I need some help on this one, as clang/test/Misc/Inputs/serialized-diags-stable.dia is a binary which needs to be regenerated, and I don't exactly know how to do that.

Diff Detail

Repository
rC Clang

Event Timeline

easyaspi314 created this revision.Apr 13 2018, 4:10 PM
rsmith added a subscriber: rsmith.Apr 13 2018, 6:22 PM
rsmith added inline comments.
bindings/python/tests/cindex/test_diagnostics.py
18

It seems like part of the problem here is that "non-void function" is sort-of nonsense due to a few missing words. How about:

"control can reach end of function with non-void return type"

or similar?

I think we still need the mention of control flow, because we're *not* saying the function contains no return statements, we're saying there's a control flow path that reaches the end of the function.

docs/DiagnosticsReference.rst
9097

This is a generated file; please don't manually update it. (Though we should regenerate it, it's probably quite stale...)

Quuxplusone added inline comments.
bindings/python/tests/cindex/test_diagnostics.py
18

I think OP's issue here is that the current message about "control" is intrinsically confusing. Of course "control can reach end of function"; if control never reaches the end of the function, you must have an infinite loop somewhere! The important missing piece of the current message is that control reaches the end of the function without encountering any return statement.

we're *not* saying the function contains no return statements

Not sure, but I think in this case we are saying that. There's a different message, "non-void function might not return a value," for those other cases.

However, if I'm wrong about that, then another wording option close to OP's suggestion would be "non-void function does not always return a value" / "non-void function might not always return a value."

include/clang/Basic/DiagnosticASTKinds.td
33

I think this should remain past-tense, since it's describing a situation that actually did happen during constexpr evaluation. That is, "constexpr function did not return a value" or "control fell off the end of this function" or some such.

easyaspi314 added inline comments.Apr 16 2018, 9:22 AM
docs/DiagnosticsReference.rst
9097

Serious question though, why in the world do we have generated files in an open source repo?

Isn't is as stupid as putting the precompiled binaries in the source tree? I'd rather wait a few minutes to generate some files than spend 4 hours trying to figure out how to deal with serialized-diags-stable.dia.

easyaspi314 added inline comments.Apr 16 2018, 9:54 AM
bindings/python/tests/cindex/test_diagnostics.py
18

I think we still need the mention of control flow.

I see where you are going.

However, I have another idea, but I can't implement it myself.

What if we give the user a note like this:

int someCondition;

int a() {
    if (someCondition) {
        return 3;
    }
}
foo.c:3:1: warning: non-void function might not return a value [-Wreturn-type]
int a() {
^
foo.c:4:5: note: assuming 'someCondition' is false
    if (someCondition) {
    ^
foo.c:7:1: note: control flow reaches end of function without a return value
}
^
1 warning generated.