Is __declspec a core language extension?

[Aaron Ballman]

Since there appears to be no major opposition to this change, I've
commit in r238238. I've also updated the release notes to reflect this
change.

I will keep my eyes peeled for unexpected complications from this
patch, and will handle them.

~Aaron

On Thu, May 21, 2015 at 6:40 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Thu, May 21, 2015 at 5:17 PM, David Majnemer
> <david.majnemer at gmail.com> wrote:
>>
>>
>> On Thu, May 21, 2015 at 1:23 PM, Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>>
>>> 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.
>>
>>
>> MSVC changes the behavior of *existing* attributes between major versions
>> (__declspec(align) and __declspec(thread_local) both changed) and we do our
>> best to give sensible results in the face of that.  We already have to deal
>> with the possibility that MSVC 20XX will behave in a way counter to how
>> we've programmed clang.
>>
>>>
>>>
>>> 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.
>>
>>
>> We already have this problem today.  Clang supports aspects of C++ which no
>> version of MSVC (or ICC for that matter) support like variable templates.
>> We chose a sensible mangling for this feature but will change our mangling
>> for compatibility if a problem shows up.
>
> We don't have this problem today. Today we support attributes
> Microsoft supports, and we try our best to ensure compatibility as
> Microsoft changes the semantics. If we start adding our own attributes
> using a __declspec spelling, that changes the game. Now we have
> customers who are using *our* attributes with our semantics, but the
> ones who also want MS compatibility make this scenario problematic if
> MS has different semantics when the implement an attribute of the same
> name. Either we continue to support customers with our semantics (not
> breaking code, but not interoperable with MSVC behavior), or we use
> Microsoft's semantics (breaking code in the process), but we can't
> always do both at the same time.
>
> Granted, this is all incredibly hypothetical. We can cross this bridge
> if we ever get to it.
>
>>
>>>
>>> >
>>> >>
>>> >>
>>> >> > 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?
>>
>>
>> I think that either possibility is OK, people guard their usage of
>> __declspec by #if.
>
> Thank you!
>
> ~Aaron
>
>>
>>>
>>>
>>> ~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
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>