[cfe-dev] [bug?] list-initialization failures in a return statement

[Jim Porter]

I've found what I think are a couple of bugs in how clang (3.4) 
list-initializes objects in a return statement. It probably applies to 
any copy-list-initialization context, but I haven't tested all the 
possibilities. I'm posting this here instead of just filing a bug 
because I wanted to get some feedback on whether I'm correct about this 
or not.

--------------------

First, I think clang is incorrectly failing on the explicit default 
constructor in this sample:

   struct foo {
     explicit foo() {}
   };

   foo make_foo() {
     return {};
   }

   int main() {
     auto f = make_foo();
     return 0;
   }

clang tells me "chosen constructor is explicit in copy-initialization", 
but according to 8.5.4p3, make_foo should be value-initializing foo:

   If the initializer list has no elements and T is a class type with a
   default constructor, the object is value-initialized.

--------------------

Second, the following seems to be trying to invoke a copy-constructor 
when it shouldn't:

   struct foo {
     foo() {}
     foo(const foo &) = delete;
     foo & operator =(const foo &) = delete;
   };

   template<typename T>
   foo make() {
     return {};
   }

   int main() {
     auto &&f = make<foo>();
     return 0;
   }

clang reports "call to deleted constructor of 'foo'". However, if I 
remove the default constructor and let clang create its own, or if I 
change the signature of make() to `template<typename T> T make()`, it 
compiles without error. It seems like clang is assuming that T is not 
the same as foo, and so tries to invoke the deleted copy constructor. 
However, if T is foo, that shouldn't matter, right?

--------------------

I haven't had a chance to test clang 3.5 yet, so it's possible these are 
already fixed, or maybe I'm just confused about things. If these are 
indeed bugs, I'd be happy to try and fix them if folks don't mind 
pointing me in the right direction.

- Jim