<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 19, 2014 at 10:02 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 17/01/2014 21:36, Richard Smith wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 17, 2014 at 6:52 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
Ping<br>
<br>
Need this to parse MSVC headers, patch rebased to ToT.<br>
<br>
<br>
Really sorry for the delay!<br>
<br>
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).<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
Thanks for pointing this out!</blockquote><div><br></div><div>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 (!!)).</div>
<div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>Sounds great, thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>Done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alp.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On 12/12/2013 17:13, Alp Toker wrote:<br>
<br>
This patch adds support for the MSVC12.0 / 2013 type trait<br>
builtin primitives sufficiently to support the new type_trait<br>
facilities added to the C++ standard library.<br>
<br>
With these clang is now more or less able to parse itself with<br>
the Visual Studio 2013 SDK.<br>
<br>
Fully Implemented:<br>
<br>
* __is_constructible()<br>
* __is_nothrow_constructible()<br>
<br>
Implemented through fallback to other type traits (WIP, noted<br>
with two TODOs):<br>
<br>
* __is_destructible()<br>
* __is_nothrow_destructible()<br>
* __is_nothrow_assignable()<br>
<br>
The patch is built on top of the other two posted earlier<br>
today unifying (1) contextual keywords and (2) the new type<br>
traits implementation.<br>
<br>
Alp.<br>
<br>
<br>
-- <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br></div>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.<u></u>edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div></div>