Since there appears to be no major opposition to this change, I've commit in r238238. I've also updated the release notes to reflect this change.
I will keep my eyes peeled for unexpected complications from this patch, and will handle them. ~Aaron On Thu, May 21, 2015 at 6:40 PM, Aaron Ballman <[email protected]> wrote: > On Thu, May 21, 2015 at 5:17 PM, David Majnemer > <[email protected]> wrote: >> >> >> 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. > > We don't have this problem today. Today we support attributes > Microsoft supports, and we try our best to ensure compatibility as > Microsoft changes the semantics. If we start adding our own attributes > using a __declspec spelling, that changes the game. Now we have > customers who are using *our* attributes with our semantics, but the > ones who also want MS compatibility make this scenario problematic if > MS has different semantics when the implement an attribute of the same > name. Either we continue to support customers with our semantics (not > breaking code, but not interoperable with MSVC behavior), or we use > Microsoft's semantics (breaking code in the process), but we can't > always do both at the same time. > > Granted, this is all incredibly hypothetical. We can cross this bridge > if we ever get to it. > >> >>> >>> > >>> >> >>> >> >>> >> > 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. > > Thank you! > > ~Aaron > >> >>> >>> >>> ~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
