Is __declspec a core language extension?

Aaron Ballman aaron at aaronballman.com
Thu May 21 11:56:33 PDT 2015


On Thu, May 21, 2015 at 2:11 PM, David Majnemer
<david.majnemer at gmail.com> wrote:
>
>
> On Wed, May 20, 2015 at 2:54 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> While refactoring some attribute parsing code, I noticed that we do
>> not guard __declspec as being a Microsoft-specific extension that we
>> support. This is consistent with the behavior we have for
>> __attribute__. In both cases, the keyword is available everywhere, and
>> specific attributes determine their target requirements. However, I
>> wonder if that's the behavior we want.
>>
>> With __attribute__, it makes some degree of sense that we support it
>> everywhere and own it as a core language extension. For instance, we
>> allow users to add GNU-style attribute spellings that GCC does not
>> support and no one takes issue.
>>
>> Do we want the same level of ownership over __declspec? If someone
>> wants to add a new attribute with a __declspec spelling that is not
>> supported by MSVC, will we allow it? I struggle to imagine us allowing
>> that as it can cause future compatibility issues if Microsoft were to
>> use the same attribute name with different semantics.
>
>
> I think we should be free to add stuff to __declspec if we don't think it is
> likely that MSVC would repurpose the same attribute for a different purpose.

I disagree, unless we get strong supporting murmurs from Microsoft on
the given attribute's likelihood (or not) of being included in Visual
Studio. __declspec is Microsoft's conforming language extension. It
seems to me like we'd be acting in bad faith if we co-opted that for
our own attributes when we have existing mechanisms that are not tied
to a proprietary compiler's language extension (like C++11 style
attributes which have an explicit scoping mechanism, or even
__attribute__, sub-optimally).

> Microsoft seems to be aware that others build tools with command lines and
> attributes compatible with their tooling. For example, they reused ICC's
> /Qvec-report flag for MSVC 2012.

If we were to start supporting compatibility with ICC, I would not be
opposed to adding ICC-specific __declspec spellings, to be clear. I'm
more against the idea of adding something like
__declspec(no_sanitize("address")) as an example.

~Aaron

>
>>
>> For that reason,
>> I think __declspec should be guarded by -fms-extensions, but I wanted
>> to get community feedback before making such a change.
>>
>> Thanks!
>>
>> ~Aaron
>
>



More information about the cfe-commits mailing list