This is an archive of the discontinued LLVM Phabricator instance.

[-Wmissing-noreturn] Detect non-void noreturn function candidates
Changes PlannedPublic

Authored by steakhal on Dec 2 2022, 5:39 AM.

Details

Summary

Previously, only void returning functions were considered for noreturn
attribute candidates. This patch removes this artificial restriction.

Notice the zero-initializations of the CheckFallThroughDiagnostics
objects. In some cases, such as inside MakeForCoroutine(), some struct
members were left uninitialized (probably by accident).
This way all the fields will be zero-initialized, preventing accidental
uninitialized reads during diagnostics construction.

Diff Detail

Event Timeline

steakhal created this revision.Dec 2 2022, 5:39 AM
Herald added a project: Restricted Project. · View Herald Transcript
steakhal requested review of this revision.Dec 2 2022, 5:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 2 2022, 5:39 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Previously, only void returning functions were considered for noreturn attribute candidates. This patch removes this artificial restriction.

C2x 6.7.12.6p6: The implementation should produce a diagnostic message for a function declared with a noreturn attribute that appears to be capable of returning to its caller.

p7 has an example showing [[noreturn]] int h(void); with the comment "Implementations are similarly encouraged to diagnose the declaration of h() because it appears capable of returning to its caller due to the non-void return type."

So is this really an artificial restriction? To me, putting the noreturn attribute on a function with a return type makes no sense whatsoever. The interface is saying "I promise that calling me will not return" and "when I return, this is the type of the value I will give you."

steakhal planned changes to this revision.Dec 2 2022, 7:56 AM

Previously, only void returning functions were considered for noreturn attribute candidates. This patch removes this artificial restriction.

C2x 6.7.12.6p6: The implementation should produce a diagnostic message for a function declared with a noreturn attribute that appears to be capable of returning to its caller.

p7 has an example showing [[noreturn]] int h(void); with the comment "Implementations are similarly encouraged to diagnose the declaration of h() because it appears capable of returning to its caller due to the non-void return type."

So is this really an artificial restriction? To me, putting the noreturn attribute on a function with a return type makes no sense whatsoever. The interface is saying "I promise that calling me will not return" and "when I return, this is the type of the value I will give you."

Hmm, I implicitly took the __attribute__((noreturn)) suggestion and the non-void return type as a code-smell for the exact same reason.
You are right, we should have a clean diagnostic message for these cases instead of this implied suggestion.
IDK why I haven't thought about this 😅