<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 1:23 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, May 21, 2015 at 4:08 PM, David Majnemer<br>
<div><div><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, May 21, 2015 at 11:56 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, May 21, 2015 at 2:11 PM, David Majnemer<br>
>> <<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Wed, May 20, 2015 at 2:54 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> While refactoring some attribute parsing code, I noticed that we do<br>
>> >> not guard __declspec as being a Microsoft-specific extension that we<br>
>> >> support. This is consistent with the behavior we have for<br>
>> >> __attribute__. In both cases, the keyword is available everywhere, and<br>
>> >> specific attributes determine their target requirements. However, I<br>
>> >> wonder if that's the behavior we want.<br>
>> >><br>
>> >> With __attribute__, it makes some degree of sense that we support it<br>
>> >> everywhere and own it as a core language extension. For instance, we<br>
>> >> allow users to add GNU-style attribute spellings that GCC does not<br>
>> >> support and no one takes issue.<br>
>> >><br>
>> >> Do we want the same level of ownership over __declspec? If someone<br>
>> >> wants to add a new attribute with a __declspec spelling that is not<br>
>> >> supported by MSVC, will we allow it? I struggle to imagine us allowing<br>
>> >> that as it can cause future compatibility issues if Microsoft were to<br>
>> >> use the same attribute name with different semantics.<br>
>> ><br>
>> ><br>
>> > I think we should be free to add stuff to __declspec if we don't think<br>
>> > it is<br>
>> > likely that MSVC would repurpose the same attribute for a different<br>
>> > purpose.<br>
>><br>
>> I disagree, unless we get strong supporting murmurs from Microsoft on<br>
>> the given attribute's likelihood (or not) of being included in Visual<br>
>> Studio. __declspec is Microsoft's conforming language extension. It<br>
>> seems to me like we'd be acting in bad faith if we co-opted that for<br>
>> our own attributes when we have existing mechanisms that are not tied<br>
>> to a proprietary compiler's language extension (like C++11 style<br>
>> attributes which have an explicit scoping mechanism, or even<br>
>> __attribute__, sub-optimally).<br>
><br>
><br>
> I fail to see how this is materially different from us adding stuff to<br>
> __attribute__.<br>
<br>
</div></div>In many regards, it isn't. We should be careful when adding GNU-style<br>
spellings that GCC doesn't support, too. However, in the case of<br>
GNU-style spellings, nothing prevents a motivated developer from<br>
adding the identical attribute to GCC. They are, however, prevented<br>
from adding it to Visual Studio in the case of a __declspec spelling.<br>
What's more, Microsoft could decide to implement the attribute with<br>
different semantics than what Clang does, and now there's a<br>
compatibility problem we have to solve.<br></blockquote><div><br></div><div><div>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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I still haven't heard a case made that we wouldn't be acting in bad<br>
faith, or increasing our potential maintenance costs, by adding our<br>
own __declspec attributes that Visual Studio doesn't support. Further,<br>
I struggle to imagine a situation where __declspec is somehow a<br>
superior spelling to __attribute__ for a newly-defined,<br>
not-supported-by-MSVC attribute.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
><br>
>><br>
>><br>
>> > Microsoft seems to be aware that others build tools with command lines<br>
>> > and<br>
>> > attributes compatible with their tooling. For example, they reused ICC's<br>
>> > /Qvec-report flag for MSVC 2012.<br>
>><br>
>> If we were to start supporting compatibility with ICC, I would not be<br>
>> opposed to adding ICC-specific __declspec spellings, to be clear. I'm<br>
>> more against the idea of adding something like<br>
>> __declspec(no_sanitize("address")) as an example.<br>
><br>
><br>
> I also think it makes sense for us to add ICC-specific __declspec spellings.<br>
> Could we make our support for align_value symmetric? We support the GNU<br>
> spelling but not the __declspec.<br>
><br>
> How is adding support for an ICC-specific __declspec different from us<br>
> adding our own?<br>
<br>
</span>Just because ICC makes a decision doesn't mean emulating that is a<br>
good decision for our product. I don't know the circumstances<br>
surrounding why ICC chose to implement __declspec attributes that MSVC<br>
doesn't support, but I still think it's poor form for Clang to do so.<br>
<br>
To bring this back onto the original topic, are you arguing that<br>
__declspec should not be controlled by -fms-extensions?<br></blockquote><div><br></div><div>I think that either possibility is OK, people guard their usage of __declspec by #if.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
~Aaron<br>
</font></span><div><div><br>
><br>
>><br>
>> ~Aaron<br>
>><br>
>> ><br>
>> >><br>
>> >> For that reason,<br>
>> >> I think __declspec should be guarded by -fms-extensions, but I wanted<br>
>> >> to get community feedback before making such a change.<br>
>> >><br>
>> >> Thanks!<br>
>> >><br>
>> >> ~Aaron<br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>