__attribute__ ((noreturn)) in a function parameter

[filcab]

Bugzilla Link	2461
Resolution	FIXED
Resolved on	Mar 12, 2010 00:57
Version	unspecified
OS	All
CC	@mrvacbob,@d0k,@edwintorok,@efriedma-quic

Extended Description

clang doesn't allow attribute ((noreturn)) in a function parameter:
[filcab@farnsworth ~] $ cat b.c
extern void LibVEX_Init (
/* failure exit function */
attribute ((noreturn))
void (*failure_exit) ( void )
);
[filcab@farnsworth ~] $ ccc -o b.o -c b.c
clang -emit-llvm-bc -x c -o b.o b.c
b.c:3:20: warning: 'noreturn' attribute only applies to function types
attribute ((noreturn))
^
1 diagnostic generated.
[filcab@farnsworth ~] $ gcc -o b.o -c b.c
[filcab@farnsworth ~] $

[efriedma-quic]

Hmm, so it appears gcc allows applying the noreturn attribute to function pointers. This is going to be a bit complicated... clang currently doesn't support attaching function attributes to types.

A slightly more straightforward testcase:
typedef int (*a)();
typedef a b __attribute((noreturn));

[filcab]

I tried taking a peek at the source but I didn't see any way to know if a certain parameter is a function type or not. Is there a way to do that or is it necessary to make some more deep changes to know that?

Also: Is there any information about how clang works internally (except for the *.{cpp,h))?

[efriedma-quic]

I tried taking a peek at the source but I didn't see any way to know if a
certain parameter is a function type or not. Is there a way to do that or is it
necessary to make some more deep changes to know that?

I haven't checked this carefully, but I think what's happening is that by the time we try to apply the noreturn attribute, we no longer have a function, but instead a function pointer. That makes your testcase internally identical to mine.

The relevant place where clang handles declaration attributes is Sema::HandleDeclAttribute.

If you have a Decl, you can get its type by calling getType().

Unfortunately, the issue here is rather complicated, because it's really an architectural bug that function attributes are associated with the function decl rather than the function type.

Also: Is there any information about how clang works internally (except for the
*.{cpp,h))?

There's some limited documentation on the website (clang.llvm.org). Feel free to ask any questions, and additional documentation is always welcome.

[llvmbot]

Another (possibly related) test case is

void f(int (attribute((stdcall)) *func)());

which gives

test.c:1:12: error: function cannot return array or function type 'int ()'
void f(int (attribute((stdcall)) *func)());
^

[lattner]

I just completed a round of significant cleanups to attribute processing stuff. Implementing this now should be pretty easy (just change these "function attributes" to be type attributes). However, the hard part is that we have no place to store these. They really should go on the function type, but those are uniqued and it is unclear how these affect type compatibility.

[lattner]

One other way to handle this is as a form of type qualifier like CVR or address spaces.

[efriedma-quic]

They really should go on the function type, but those
are uniqued and it is unclear how these affect type compatibility.

Yeah, that's kind of tricky... I'd suggest that for attributes like noreturn, which don't affect the calling convention, function types with and without the attribute should be compatible, and for attributes that affect the ABI (like stdcall), the function types should be incompatible. (This isn't really typesafe, but C fundamentally isn't typesafe in this respect anyway.)

Here's an interesting question (although I suppose it's only partly on-topic): suppose you have a pointer to a function returning a function pointer, and this declaration is decorated with __attribute((noreturn)). Which function is affected? And where would you place the attribute specifier to affect the other function?

[llvmbot]

This appears to be fixed in trunk.

[efriedma-quic]

I wouldn't really call it fixed; we're simply ignoring it now.

[edwintorok]

I wouldn't really call it fixed; we're simply ignoring it now.

It is not fixed, compilation fails with this error now:
priv/main/vex_util.c:221:1: error: function declared 'noreturn' should not return [-Winvalid-noreturn]

Since clang doesn't know that noreturn applies to function pointers, it doesn't know that vex_failure_exit is noreturn, and thinks it may return.

[nunoplopes]

*** Bug llvm/llvm-bugzilla-archive#5402 has been marked as a duplicate of this bug. ***

[nunoplopes]

*** Bug llvm/llvm-bugzilla-archive#5280 has been marked as a duplicate of this bug. ***

[nunoplopes]

*** Bug llvm/llvm-bugzilla-archive#5578 has been marked as a duplicate of this bug. ***

[llvmbot]

I noticed something interesting about clang's behavior in this case. If when you declare the function pointer, you put the noreturn attribute at the beginning of the declaration, clang warns:

$ cat t.c
attribute((noreturn)) void f(attribute((noreturn)) void (*x)(void))
{
x();
}

$ clang -c t.c
t.c:6:1: warning: function declared 'noreturn' should not return
[-Winvalid-noreturn]
}
^
1 diagnostic generated.
$

But when you put it at the end of the declaration, it doesn't warn:

$ cat t.c
attribute((noreturn)) void f(void (*x)(void) attribute((noreturn)))
{
x();
}

$ clang -c t.c
$

Correct me if I'm wrong, but I think that the noreturn is getting applied to the return type of the function pointer in the first case, instead of the function pointer itself. In the second case, clang is correctly applying noreturn to the function pointer type.

[llvmbot]

Correct me if I'm wrong, but I think that the noreturn is getting applied to
the return type of the function pointer in the first case, instead of the
function pointer itself.
Or, the attribute for some strange reason is being silently ignored. It just occurred to me that if clang really did try to apply noreturn to the void type, it would have printed a warning to the effect of the attribute only applying to function types.

Now the question is: why is the attribute ignored when it's at the beginning of the decl but applied when it's at the end?