[LLVMbugs] [Bug 21787] __has_trivial_constructor is true for lambdas

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21787

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |mclow.lists at gmail.com
         Resolution|---                         |FIXED

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> ---
(In reply to comment #2)
> So if it is correct in Clang, is it a bug in both GCC and Boost?

It's sort-of a bug in GCC, and very likely to be a bug in boost. boost is
relying on a property that is not guaranteed by this trait: the fact that a
type T has a trivial default constructor does *not* imply that the expression
T() is well-formed.

boost will presumably do the wrong thing under GCC if your callable object has
a private defaulted default constructor (for which __has_trivial_constructor is
true but the type is not trivially constructible).


> (Also all the clang docs say about __has_trivial_constructor is that it
> should be working as it does with GCC and MSVC.)

It essentially does. The difference is that internally Clang decides
(correctly, per C++11) that the closure type has a trivial default constructor,
and GCC and MSVC presumably do not.

Now, we voted a last-minute change into C++14 that says closure types have no
default constructor rather than having a deleted default constructor, and that
will make __has_trivial_constructor(LambdaType) always be false. I've
implemented that in r223953, which should make the symptom here go away, but
the root cause (that boost is misusing this broken-by-design type trait) will
remain.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141210/f3c791ad/attachment.html>