On Thu, May 21, 2015 at 11:56 AM, Aaron Ballman <[email protected]> wrote:
> On Thu, May 21, 2015 at 2:11 PM, David Majnemer > <[email protected]> wrote: > > > > > > On Wed, May 20, 2015 at 2:54 PM, Aaron Ballman <[email protected]> > > 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 > > > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
