[PATCH] MSVC 2013 type trait support

[Richard Smith]

On Sun, Jan 19, 2014 at 10:02 AM, Alp Toker <alp at nuanti.com> wrote:

>
> On 17/01/2014 21:36, Richard Smith wrote:
>
>  On Fri, Jan 17, 2014 at 6:52 AM, Alp Toker <alp at nuanti.com <mailto:
>> alp at nuanti.com>> wrote:
>>
>>     Ping
>>
>>     Need this to parse MSVC headers, patch rebased to ToT.
>>
>>
>> Really sorry for the delay!
>>
>> For the 'nothrow' tests, please use Sema::canThrow rather than checking
>> the exception specification (that way, you'll also handle exceptions within
>> default arguments, exceptions within the conversion sequences for the
>> parameters, and so on).
>>
>
> On balance there's no need for bug-for-bug compatibility here so yes,
> let's do the right thing. The patch was developed from a description of
> MSVC behaviour but I've reached the conclusion they've simply made a pig's
> ear of it.
>
> As a note, the MS built-in __has_*constructor() primitives only seem to
> check the first ctor in cases where there are multiple constructors defined
> -- another behaviour we certainly don't want.
>
> Thanks for pointing this out!


No problem! For what it's worth, the GCC-compatible parts of our __has_*
implementation try to be bug-compatible with GCC, which means they do
really weird things in corner cases too (in particular, in the case where a
class has both a trivial and a non-trivial foo, __has_trivial_foo gives an
odd answer (!!)).

I think our policy should be to give the right answer for these builtins
(directly following [meta] in the C++ standard, unless we have a concrete
compatibility reason to give a different answer (for instance, because
libstdc++ directly depends on us lying to it).


>  Please also *don't* return true if the construction is trivial but not
>> noexcept -- that doesn't match what the standard requires from these traits.
>>
>> If you're intending on providing follow-up patches implementing the other
>> stubbed-out traits, I'm OK with them being broken in the interim (it's a
>> good start); otherwise I'd like for them to be diagnosed rather than
>> silently giving the wrong answers.
>>
>
> It's worth getting these into SVN to stem bug reports -- failure to parse
> is the most reported issue. So I'll land with the __is_*constructive()
> checks as KEYALL now that it looks like the semantics will be generally
> useful, and keep the unimplemented cases as KEYMS with a view to completing
> their implementations shortly.
>

Sounds great, thanks!


> Richard, if you have a minute could you review my proposal "Type trait
> primitives and feature detection" taking into account r199562 -- that's the
> roadmap I've set out for getting trait feature detection and documentation
> back in order and I'd appreciate your second opinion.
>

Done.


> Alp.
>
>
>
>> On 12/12/2013 17:13, Alp Toker wrote:
>>
>>         This patch adds support for the MSVC12.0 / 2013 type trait
>>         builtin primitives sufficiently to support the new type_trait
>>         facilities added to the C++ standard library.
>>
>>         With these clang is now more or less able to parse itself with
>>         the Visual Studio 2013 SDK.
>>
>>         Fully Implemented:
>>
>>         * __is_constructible()
>>         * __is_nothrow_constructible()
>>
>>         Implemented through fallback to other type traits (WIP, noted
>>         with two TODOs):
>>
>>         * __is_destructible()
>>         * __is_nothrow_destructible()
>>         * __is_nothrow_assignable()
>>
>>         The patch is built on top of the other two posted earlier
>>         today unifying (1) contextual keywords and (2) the new type
>>         traits implementation.
>>
>>         Alp.
>>
>>
>>     --     http://www.nuanti.com
>>     the browser experts
>>
>>
>>     _______________________________________________
>>     cfe-commits mailing list
>>     cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140119/1a45736a/attachment.html>