On Sun, Jan 19, 2014 at 10:02 AM, Alp Toker <[email protected]> wrote: > > On 17/01/2014 21:36, Richard Smith wrote: > > On Fri, Jan 17, 2014 at 6:52 AM, Alp Toker <[email protected] <mailto: >> [email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> > -- > http://www.nuanti.com > the browser experts > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
