<div dir="ltr">+1 for throwing it under -fms-extensions.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 20, 2015 at 2:54 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. 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>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br></div>