On Thu, May 21, 2015 at 1:23 PM, Aaron Ballman <[email protected]> wrote:
> On Thu, May 21, 2015 at 4:08 PM, David Majnemer > <[email protected]> wrote: > > > > > > 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__. > > In many regards, it isn't. We should be careful when adding GNU-style > spellings that GCC doesn't support, too. However, in the case of > GNU-style spellings, nothing prevents a motivated developer from > adding the identical attribute to GCC. They are, however, prevented > from adding it to Visual Studio in the case of a __declspec spelling. > What's more, Microsoft could decide to implement the attribute with > different semantics than what Clang does, and now there's a > compatibility problem we have to solve. > 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. > > I still haven't heard a case made that we wouldn't be acting in bad > faith, or increasing our potential maintenance costs, by adding our > own __declspec attributes that Visual Studio doesn't support. Further, > I struggle to imagine a situation where __declspec is somehow a > superior spelling to __attribute__ for a newly-defined, > not-supported-by-MSVC attribute. > 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. > > > >> > >> > >> > 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? > > Just because ICC makes a decision doesn't mean emulating that is a > good decision for our product. I don't know the circumstances > surrounding why ICC chose to implement __declspec attributes that MSVC > doesn't support, but I still think it's poor form for Clang to do so. > > To bring this back onto the original topic, are you arguing that > __declspec should not be controlled by -fms-extensions? > I think that either possibility is OK, people guard their usage of __declspec by #if. > > ~Aaron > > > > >> > >> ~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
