[llvm-bugs] [Bug 32072] Class no longer convertible after declaration member of type std::function<Class()>

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Feb 1 08:05:32 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=32072

Casey Carter <Casey at Carter.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |Casey at Carter.net
         Resolution|---                         |INVALID

--- Comment #3 from Casey Carter <Casey at Carter.net> ---
This is not a bug in clang: it's a defect in the specification of
std::function's conversion constructor template that I worked around in the
MSVC STL in August of 2017. It is fixed in the current release of VS2017.

In detail: std::function<T(Args...)> has a conversion constructor template that
accepts an argument of any type that is callable with Args... and returns a
type that is convertible to T. 

At the closing brace in the definition of:

struct B {
  std::function<C()> f;
};

the compiler is required to generate the implicitly-defined copy constructor
for B. To determine if that copy constructor should be deleted, it performs
overload resolution to determine if each of the members of B is copy
constructible. For f, that means it must determine if an object of type
std::function<C()> can be initialized from an lvalue expression of type const
std::function<C()>. 

There are two candidate constructors for that initialization: std::function's
implicitly-defined copy constructor, and its conversion constructor template.
To determine if the conversion constructor template is viable it has to check
the constraints: 

* "Can I call a std::function<C(Args...)> with Args...?" Yes.
* "Is the return type C convertible to C?" If implemented with
is_convertible_v<C, C>, which we do, results in undefined behavior when C is an
incomplete type.

We now guard the conversion constructor template against being used for copy
and move construction. I suspect the other Standard Libraries do as well, but
that behavior isn't guaranteed by the Standard.

-- 
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/20190201/cd309fa8/attachment-0001.html>


More information about the llvm-bugs mailing list