Overly pedantic [[noreturn]] restriction

[kimbarrett]

C++11 says that the first declaration of a function must specify the [[noreturn]] attribute if any declaration specifies it.

All of gcc, clang, and MSVC provide compiler-specific mechanisms to indicate a function is "noreturn". gcc and clang have attribute((noreturn)), while MSVC has __declspec(noreturn). gcc and MSVC treat their compiler-specific attributes as satisfying the first declaration attribute requirement, but clang does not. That is, this compiles cleanly with gcc, but clang issues a warning

attribute((noreturn)) void testfn(int);
[[noreturn]] void testfn(int);

and this compiles cleanly with MSVC, but clang issues a warning

__declspec(noreturn) void testfn(int);
[[noreturn]] void testfn(int);

[frederick-vs-ja]

Currently GCC and Clang consider __attribute__((noreturn)) affect the function type while [[noreturn]] doesn't (Godbolt link). See also #113511.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Kim Barrett (kimbarrett)

C++11 says that the first declaration of a function must specify the `[[noreturn]]` attribute if any declaration specifies it.

All of gcc, clang, and MSVC provide compiler-specific mechanisms to indicate a function is "noreturn". gcc and clang have attribute((noreturn)), while MSVC has __declspec(noreturn). gcc and MSVC treat their compiler-specific attributes as satisfying the first declaration attribute requirement, but clang does not. That is, this compiles cleanly with gcc, but clang issues a warning

attribute((noreturn)) void testfn(int);
[[noreturn]] void testfn(int);

and this compiles cleanly with MSVC, but clang issues a warning

__declspec(noreturn) void testfn(int);
[[noreturn]] void testfn(int);

[llvmbot]

@llvm/issue-subscribers-c-1

Author: Kim Barrett (kimbarrett)

C++11 says that the first declaration of a function must specify the `[[noreturn]]` attribute if any declaration specifies it.

All of gcc, clang, and MSVC provide compiler-specific mechanisms to indicate a function is "noreturn". gcc and clang have attribute((noreturn)), while MSVC has __declspec(noreturn). gcc and MSVC treat their compiler-specific attributes as satisfying the first declaration attribute requirement, but clang does not. That is, this compiles cleanly with gcc, but clang issues a warning

attribute((noreturn)) void testfn(int);
[[noreturn]] void testfn(int);

and this compiles cleanly with MSVC, but clang issues a warning

__declspec(noreturn) void testfn(int);
[[noreturn]] void testfn(int);

[frederick-vs-ja]

Also, this issue seem to be C++-only. In C23 mode (and probably, older C modes), both GCC and Clang doesn't think __attribute__((noreturn)) affect function types (Godbolt link).

[kimbarrett]

I tripped over this issue while working on
https://bugs.openjdk.org/browse/JDK-8313396 Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION

[AaronBallman]

It doesn't seem overly pedantic to me; [[noreturn]] is a standard attribute and the standards committees have different rules for their attribute than the prior art with __attribute__ or __declspec, so I don't think the non-standard forms are a valid spelling of [[noreturn]] (esp because WG21 has repeatedly changed the rules for attributes over the years, so even if they're "equivalent enough" today, there's no reason to believe that will remain true in the future). So I think this is more of a bug with GCC and MSVC than it is with Clang per https://eel.is/c++draft/dcl.attr.noreturn#1.sentence-4.

However, I can definitely see why a reasonable user would think this is being overly pedantic. The usual expectation is that these three are equivalent even though they're not.

CC @erichkeane for additional opinions.

[erichkeane]

TYPICALLY I would agree with the submitter here, but noreturn is actually kinda special here. The GCC noreturn that we implement is significantly different in behavior (and thus implementation) than the C++ version. I'd have to look closer at how we're using the declspec version, but this is really a problem of the standard attribute using the same name as something and not perfectly recreating its semantics.

So I have sympathy here, and would be open to discussion, but I'm not convinced this is a bug.

[kimbarrett]

The issue was encountered because we (openjdk) are attempting to prevent the direct use of certain third-party (to us) library functions in our code. (There are a variety of reasons we might want to do this, depending on the function in question.)

The approach being taken is to declare such a function deprecated, using the standard [[deprecated]] attribute. Obviously that involves a declaration. It might be a forward declaration, or might be a redeclaration, depending on whether the relevant header has already been included. (We can't reliably ensure it hasn't.) For "noreturn" functions, the library might be using [[noreturn]] or it might be using __attribute__ or __declspec.

So when building with clang

(1) We can't just use [[noreturn]], because that would fail if we're redeclaring and the library uses the other form.

(2) We can't just use the other form, because that would fail if we're forward declaring the library uses [[noreturn]].

During our configure step we could try to detect what form the library uses, and be consistent with that. Of course, that becomes more complicated if we ever need to deal with multiple libraries that differ in this respect. Or even one library that isn't globally consistent.

We build with other compilers besides clang, so a very clang-specific solution isn't wonderful. Our current workaround is that when building with clang we ensure the library declaration is already present and unconditionally use the other form. It would be nice to not have to forever carry this workaround forward. Especially since it seems, from my POV, an unnecessary problem to have to deal with.