This is an archive of the discontinued LLVM Phabricator instance.

[C2x] Implement WG14 N2764 the [[noreturn]] attribute
ClosedPublic

Authored by aaron.ballman on Feb 14 2022, 5:29 AM.

Details

Summary

This adds support for http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf, which was adopted at the Feb 2022 WG14 meeting. That paper adds [[noreturn]] and [[_Noreturn]] to the list of supported attributes in C2x. These attributes have the same semantics as the [[noreturn]] attribute in C++.

The [[_Noreturn]] attribute was added as a deprecated feature so that translation units which include <stdnoreturn.h> do not get an error on use of [[noreturn]] because the macro expands to _Noreturn. Users can use -Wno-deprecated-attributes to silence the diagnostic.

Use of <stdnotreturn.h> or the noreturn macro were both deprecated. Users can define the _CLANG_DISABLE_CRT_DEPRECATION_WARNINGS macro to suppress the deprecation diagnostics coming from the header file.

Diff Detail

Event Timeline

aaron.ballman requested review of this revision.Feb 14 2022, 5:29 AM
aaron.ballman created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2022, 5:29 AM
erichkeane accepted this revision.Feb 14 2022, 6:31 AM
This revision is now accepted and ready to land.Feb 14 2022, 6:31 AM
aaron.ballman closed this revision.Feb 14 2022, 6:40 AM

Thanks for the quick review. I've landed in 5029dce492b3cf3ac191eda0b5bf268c3acac2e0, but if anyone has post commit review comments (I landed this pretty quickly after initial review), I'm happy to address them.

jyknight added inline comments.Feb 14 2022, 8:53 AM
clang/lib/Headers/stdnoreturn.h
19

Is this actually useful? Isn't it sufficient to have the include-time warning for this header?

22

Would be nice to mention the solution, as well. E.g.

"The '<stdnoreturn.h>' header has been deprecated in C2x: including it no longer necessary in order to use 'noreturn'. "

clang/test/Sema/c2x-noreturn.c
41–43

If you've written [[noreturn]] in your code, you're doing the right thing already. Why bother emitting a warning? The problem that should be corrected is at the point of inclusion of stdnoreturn.h, not the spelling here.

I'd suggest only warning about "[[_Noreturn]]" if the user actually wrote it like that, and not when it's expanded from the "noreturn" macro.

aaron.ballman added inline comments.Feb 14 2022, 9:33 AM
clang/lib/Headers/stdnoreturn.h
19

I think it gives a more precise diagnostic than the header inclusion one, and it will diagnose closer to where the use happens instead of at the include. Might not be the most useful, but it I think there's some utility.

22

I can add that, but it is necessary in order to use 'noreturn' as a function specifier, so that wording isn't quite right. e.g., noreturn void func(void); is valid C today if you #include <stdnoreturn.h>

clang/test/Sema/c2x-noreturn.c
41–43

I'd suggest only warning about "[[_Noreturn]]" if the user actually wrote it like that, and not when it's expanded from the "noreturn" macro.

I'm not keen on that design. The goal of this diagnostic is to let people know that they have a surprise in their code (that this macro is expanding to something they may not expect) at the location the surprise happens. Consider:

// TU.c
#include <stdnoreturn.h>
#include "my_header.h"

// my_header.h
[[noreturn]] void func(void);

my_header.h doesn't see the inclusion of stdnoreturn.h, so finding out about the macro may inform the developer to be more protective of using the attribute.

jyknight added inline comments.Feb 14 2022, 10:01 AM
clang/lib/Headers/stdnoreturn.h
22

Ah, I missed that subtlety. Maybe say:

"The '<stdnoreturn.h>' header has been deprecated in C2x; either use the _Noreturn keyword or the [[noreturn]] attribute."

clang/test/Sema/c2x-noreturn.c
41–43

But that's exactly my point. There _is_ no surprise in this code. It works exactly as expected.
The my_header.h code is using the new non-deprecated spelling, and is getting the correct and desired behavior -- even though someone else has included stdnoreturn.h. That it's working properly due to there existing a compatibility attribute "_Noreturn" is basically an irrelevant detail to any user.

Emitting any warnings for this line of code seems potentially even harmful. Consider: what should my_header.h be doing differently due to the warning? Nothing. Ideally, they should change nothing. Yet, if we do emit warnings for this usage, it'll likely cause some people to try to add push/undef/pop gunk to their headers to avoid the warning, which makes the code worse than if they did nothing.

aaron.ballman added inline comments.Feb 14 2022, 10:24 AM
clang/lib/Headers/stdnoreturn.h
19

Okay, I've convinced myself to remove this a well for the same reason we don't want to warn on [[noreturn]] which expands to [[_Noreturn]] -- the issue isn't with use of the attribute, it's with use of the header file. I don't want to risk a user writing [[noreturn]] and hearing that the noreturn macro is deprecated and they think that means that [[noreturn]] is deprecated.

22

Sure, I can go with that.

clang/test/Sema/c2x-noreturn.c
41–43

Okay, thank you for sticking with me, that logic makes sense to me. I'll remove the diagnostic in this case.

I've made the requested changes from @jyknight in a766545402d8569532294d097d026cf2e837b5c2 -- please let me know if there are more issues you'd like me to address. Thank you for the post-commit feedback!