[PATCH] New syntax and functionality for __has_attribute

Aaron Ballman aaron at aaronballman.com
Sat Jan 11 13:13:10 PST 2014


On Sat, Jan 11, 2014 at 3:56 PM, Nico Rieck <nico.rieck at gmail.com> wrote:
> On 11.01.2014 21:06, Aaron Ballman wrote:
>> #if __has_attribute(dllexport)
>>   #define DLLEXPORT __attribute__((dllexport))
>> #else
>>   #define DLLEXPORT
>> #endif
>>
>> void func(void) DLLEXPORT;
>>
>> If you were to use this code today in clang, it would fail to compile.
>>  __has_attribute(dllexport) will be replaced with 1, and so the
>> resulting code would become: void func(void)
>> __attribute__((dllexport));  However, we do not support dllexport with
>> that syntax (we only support __declspec(dllexport)). So the code would
>> look reasonable, but fail to compile.
>
> How will a more advanced __has_attribute help here since GCC and MSVC
> all reject this trailing attribute (and Clang rightfully warns about this)?

It was meant to be expository in that there are situations where the
syntax support differs. The same statement would be true were the
attribute positioned properly. clang supports __declspec(dllexport),
but does not support __attribute__((dllexport)).

However, I did notice something interesting -- we don't support that
syntax in a declarative sense (Attr.td does not list a spelling for
it), but dllexport and dllimport are silently accepted by clang and
the attributes are attached to the decl. That doesn't really change
the desire for this feature (it's not meant as a way to handle
dllexport -- more general than that), but it is something I am
exploring a bit further as that should not be the case.

~Aaron



More information about the cfe-commits mailing list