This is an archive of the discontinued LLVM Phabricator instance.

Apply function attributes through array declarators
ClosedPublic

Authored by chill on Feb 25 2020, 2:37 AM.

Details

Summary

There's inconsistency in handling array types between the distributeFunctionTypeAttrXXX functions
and the FunctionTypeUnwrapper in SemaType.cpp.

This patch lets FunctionTypeUnwrapper apply function type attributes through
array types.

Diff Detail

Event Timeline

chill created this revision.Feb 25 2020, 2:37 AM

This will make us incompatible with how GCC behaves, won't it? Assuming yes, do you know if GCC is looking to make the same change on their end?

clang/lib/Sema/SemaType.cpp
6613

No else after a return (same for the next else as well).

6623

I'd convert this last one to use cast<> instead of dyn_cast and rely on the assertion to trigger if we got something other than an incomplete array type.

chill added a comment.Mar 16 2020, 9:01 AM

This will make us incompatible with how GCC behaves, won't it? Assuming yes, do you know if GCC is looking to make the same change on their end?

GCC behaviour is rather inconsistent and IMHO is more accidental than deliberate. I have created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94196

FWIW, Clang handling of attributes already differs from GCCs. https://gcc.godbolt.org/z/jUnGER

aaron.ballman added subscribers: rjmccall, rsmith.

I'm a bit uncomfortable with the change because the attribute appertains to a function but it is being written on an array, and this just magically "moves" the declaration around to the function type. That sort of behavior is an utter mystery of GNU-style attributes, and I am not certain that we want to add more mystery here. I'm CC'ing @rsmith and @rjmccall to see if they have opinions on the behavior.

chill updated this revision to Diff 250601.Mar 16 2020, 11:21 AM
chill marked 2 inline comments as done.
rjmccall accepted this revision.Mar 18 2020, 2:10 PM

This will make us incompatible with how GCC behaves, won't it? Assuming yes, do you know if GCC is looking to make the same change on their end?

GCC behaviour is rather inconsistent and IMHO is more accidental than deliberate. I have created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94196

FWIW, Clang handling of attributes already differs from GCCs. https://gcc.godbolt.org/z/jUnGER

Okay, I tweaked this to clarify the behavior as best as I can: https://gcc.godbolt.org/z/sooFZK

Basically, GCC handles the attribute when it's directly on a function declaration, a function-pointer declaration, or a typedef to a function-pointer type, and it propagates the attribute on pointer-to-function types (includes pointers to attributed typedefs), but it doesn't accept it on more complex declarators. In contrast, Clang aggressively looks for a function type to apply it to and then propagates it reliably.

We can't pretend to be perfectly compatible with the GCC model here. Given the Clang model, I think this is a good fix.

This revision is now accepted and ready to land.Mar 18 2020, 2:10 PM
aaron.ballman accepted this revision.Mar 19 2020, 6:20 AM

This will make us incompatible with how GCC behaves, won't it? Assuming yes, do you know if GCC is looking to make the same change on their end?

GCC behaviour is rather inconsistent and IMHO is more accidental than deliberate. I have created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94196

FWIW, Clang handling of attributes already differs from GCCs. https://gcc.godbolt.org/z/jUnGER

Okay, I tweaked this to clarify the behavior as best as I can: https://gcc.godbolt.org/z/sooFZK

Basically, GCC handles the attribute when it's directly on a function declaration, a function-pointer declaration, or a typedef to a function-pointer type, and it propagates the attribute on pointer-to-function types (includes pointers to attributed typedefs), but it doesn't accept it on more complex declarators. In contrast, Clang aggressively looks for a function type to apply it to and then propagates it reliably.

We can't pretend to be perfectly compatible with the GCC model here. Given the Clang model, I think this is a good fix.

I took a look through our attributes and we don't have any that would prefer to appertain to the array declaration rather than the function declaration (and I'm unaware of any such attributes in the works), which was my other concern with this patch. Coupled with what @rjmccall says above, I agree that this seems reasonable.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 23 2020, 4:21 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript