Is __declspec a core language extension?

[Aaron Ballman]

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