Is __declspec a core language extension?

[David Majnemer]

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


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


> ~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/04cacfe1/attachment.html>