Is __declspec a core language extension?

[Aaron Ballman]

On Thu, May 21, 2015 at 4:08 PM, David Majnemer
<david.majnemer at gmail.com> wrote:
>
>
> On Thu, May 21, 2015 at 11:56 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> 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).
>
>
> I fail to see how this is materially different from us adding stuff to
> __attribute__.

In many regards, it isn't. We should be careful when adding GNU-style
spellings that GCC doesn't support, too. However, in the case of
GNU-style spellings, nothing prevents a motivated developer from
adding the identical attribute to GCC. They are, however, prevented
from adding it to Visual Studio in the case of a __declspec spelling.
What's more, Microsoft could decide to implement the attribute with
different semantics than what Clang does, and now there's a
compatibility problem we have to solve.

I still haven't heard a case made that we wouldn't be acting in bad
faith, or increasing our potential maintenance costs, by adding our
own __declspec attributes that Visual Studio doesn't support. Further,
I struggle to imagine a situation where __declspec is somehow a
superior spelling to __attribute__ for a newly-defined,
not-supported-by-MSVC attribute.

>
>>
>>
>> > 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.
>
>
> I also think it makes sense for us to add ICC-specific __declspec spellings.
> Could we make our support for align_value symmetric? We support the GNU
> spelling but not the __declspec.
>
> How is adding support for an ICC-specific __declspec different from us
> adding our own?

Just because ICC makes a decision doesn't mean emulating that is a
good decision for our product. I don't know the circumstances
surrounding why ICC chose to implement __declspec attributes that MSVC
doesn't support, but I still think it's poor form for Clang to do so.

To bring this back onto the original topic, are you arguing that
__declspec should not be controlled by -fms-extensions?

~Aaron

>
>>
>> ~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
>> >
>> >
>
>