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