Is __declspec a core language extension?

[David Majnemer]

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.


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


>
> ~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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150521/a02acf5d/attachment.html>