Thank you for addressing the issue, and again I highly appreciate the explanations as it is quite educating for me when debugging my own errors. <div><br></div><div>I now I have a great reason to get clang running from trunk.<div>
<br></div><div>Cheers,</div><div>Rich<br><br><div class="gmail_quote">On Mon, Jul 16, 2012 at 12:23 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com" target="_blank">hhinnant@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Jul 15, 2012, at 7:40 PM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
<br>
> On Jul 15, 2012, at 3:50 PM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
><br>
>> On Jul 15, 2012, at 3:59 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>><br>
>>> I'm not sure why instantiating std::function<void(X&)>::operator= would require X to be complete -- libstdc++ does not behave that way. It's possible this is a bug in libc++, but it's also possible that the standard allows this behavior and libstdc++ is just more permissive. Hopefully Howard can help with that part.<br>
>><br>
>> Just fyi, I'm not ignoring this question. I just haven't figured out yet why I'm requiring complete types. Working...<br>
><br>
> This is arguably a bug in libc++, but I need some more time before I'm ready to fix it.<br>
><br>
> libc++ has a conforming extension for std::function to check and see if the F in:<br>
><br>
><br>
> template<class F> function& operator=(F&&);<br>
><br>
> is callable. The standard requires that F be callable for argument types ArgTypes and return type R, but the onus is on the client to meet that requirement. Failure to do so results in undefined behavior. libc++'s extension is to enforce that requirement and thus emit a diagnostic if the client fails to meet it:<br>
><br>
> template<class _Fp><br>
> typename enable_if<br>
> <<br>
> __callable<typename decay<_Fp>::type>::value,<br>
> function&<br>
>> ::type<br>
> operator=(_Fp&&);<br>
><br>
> __callable builds on __invokable and __invoke_of, which are implementation details originally invented for other parts of libc++, and only applied to std::function relatively recently.<br>
><br>
> When these traits were first invented, they were used in async and bind. In this bug:<br>
><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=9975" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=9975</a><br>
><br>
> Richard helped me diagnose this invalid program:<br>
><br>
> #include <functional><br>
> //#include <string><br>
><br>
> using namespace std::placeholders;<br>
><br>
> template <typename Functor><br>
> static void doIt(Functor f)<br>
> {<br>
> f("");<br>
> }<br>
><br>
> void method(const std::string&) {}<br>
><br>
> int main()<br>
> {<br>
> doIt(std::bind(&method, _1));<br>
> }<br>
><br>
> (I forgot to #include <string>). The error message was so terrible that it took Richard's expertise to debug this. At that time I decided to add "complete type" checks to __invokable, which greatly increased the quality of the error message of the above ill-formed program. Now even a mortal such as myself could debug it.<br>
><br>
> Subsequently, and much later, the std::function's __callable inherited those complete type checks.<br>
><br>
> If we really need to relax the complete-type-check for function, I could split the __invokable trait: have one with complete type checks for bind, and one without for function. But for tonight, this explanation of what has happened is as far as I'm getting.<br>
><br>
> Comments/suggestions most welcome.<br>
<br>
<br>
</div></div>I've committed a fix to this problem in revision 160285.<br>
<br>
Index: include/type_traits<br>
===================================================================<br>
--- include/type_traits (revision 160055)<br>
+++ include/type_traits (working copy)<br>
@@ -2853,7 +2853,7 @@<br>
<br>
template <class _Fp, class ..._Args><br>
struct __invokable_imp<br>
- : private __check_complete<_Fp, _Args...><br>
+ : private __check_complete<_Fp><br>
{<br>
typedef decltype(<br>
__invoke(_VSTD::declval<_Fp>(), _VSTD::declval<_Args>()...)<br>
<br>
And added a regression test:<br>
<br>
Index: test/utilities/function.objects/func.wrap/func.wrap.func/func.wrap.func.con/F_incomplete.pass.cpp<br>
===================================================================<br>
--- test/utilities/function.objects/func.wrap/func.wrap.func/func.wrap.func.con/F_incomplete.pass.cpp (revision 0)<br>
+++ test/utilities/function.objects/func.wrap/func.wrap.func/func.wrap.func.con/F_incomplete.pass.cpp (revision 0)<br>
@@ -0,0 +1,29 @@<br>
+//===----------------------------------------------------------------------===//<br>
+//<br>
+// The LLVM Compiler Infrastructure<br>
+//<br>
+// This file is dual licensed under the MIT and the University of Illinois Open<br>
+// Source Licenses. See LICENSE.TXT for details.<br>
+//<br>
+//===----------------------------------------------------------------------===//<br>
+<br>
+// <functional><br>
+<br>
+// class function<R(ArgTypes...)><br>
+<br>
+// template<class F> function(F);<br>
+<br>
+// Allow incomplete argument types in the __is_callable check<br>
+<br>
+#include <functional><br>
+<br>
+struct X{<br>
+ typedef std::function<void(X&)> callback_type;<br>
+ virtual ~X() {}<br>
+private:<br>
+ callback_type _cb;<br>
+};<br>
+<br>
+int main()<br>
+{<br>
+}<br>
<br>
I believe this is the highest quality fix. Good error messages will still be generated under bind and function for all of the problematic cases I'm aware of. But it will allow incomplete types to be used for arguments for those cases where the language allows.<br>
<br>
Thanks for bringing this to my attention Rich. And thanks for the investigation Richard and Steve.<br>
<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
<br>
</font></span></blockquote></div><br></div></div>