[clang] Add test for CWG2396

[Endill]

Summary

Also mark CWG1291 as "na".

P1787: CWG1291 and CWG2396 are resolved by explicitly specifying how to look up names in a conversion-type-id.
Wording: see changes to [basic.lookup.unqual]/5 and [basic.lookup.qual]/2.

"Calling a conversion function" example in P1787 is also relevant.

[shafik]

You mention CWG2385 as na but you don't explain how it was resolved, was it superceded by p1787.

Also nitpick you mentioned P1787 in the description but it links to a phab review, you should probably just use a link like I did above to refer to papers. Same with the defect reports also like I did above. Folks may not know how to find defect reports and or papers.

[Endill]

In D142316#4073771, @shafik wrote:

You mention CWG2385 as na but you don't explain how it was resolved, was it superceded by p1787.

CWG2385 points out to inconsistency in wording introduced by resolution of CWG1111, so I consider it a pure wording change. This issue, as well as aforementioned CWG1111, were resolved independently of P1787, hence I didn't provide any explanation for them.

In D142316#4073771, @shafik wrote:

Also nitpick you mentioned P1787 in the description but it links to a phab review, you should probably just use a link like I did above to refer to papers. Same with the defect reports also like I did above. Folks may not know how to find defect reports and or papers.

I felt that it's going to worsen the readability of raw commit messages, but I can indeed use markdown links if it helps.

[Endill]

Move CWG2385 out to D142315, because it's been resolved prior to P1787, and it's easier to explain it there.

[shafik]

clang/test/CXX/drs/dr23xx.cpp

202

While gcc accepts the first three it does not like the last two: https://godbolt.org/z/js8Pz14Eo

I believe they should also be covered but not confident.

[Endill]

clang/test/CXX/drs/dr23xx.cpp

202

I agree they should. I can't find any special considerations in the standard regarding unqualified name lookup of template arguments.

Are there any action items for me here?

[shafik]

clang/test/CXX/drs/dr23xx.cpp

202

Yeah, can you file a gcc bug report for the last two? If they agree it is a gcc but then we are all good, if not then we need to see what they say.

[Endill]

clang/test/CXX/drs/dr23xx.cpp

202

Upon closer inspection, I think I'm wrong to put those two tests that GCC does not accept:

1. basic.lookup.unqual#5: An unqualified name that is a component name of a type-specifier or ptr-operator of a conversion-type-id is looked up in the same fashion as the conversion-function-id in which it appears

2. expr.prim.id.unqual#2: A component name of an unqualified-id U is: — U if it is a name or; — the component name of the template-id or type-name of U, if any.

3. temp.names#2: The component name of a simple-template-id, template-id, or template-name is the first name in it

As I understand it now, identity is a component name of ptr-declarator and falls under "is looked up in the same fashion as the conversion-function-id in which it appears", but its argument B does not.

[Endill]

Remove two examples with identity<B> for reasons explained in D142316#4121079.

[shafik]

LGTM

clang/test/CXX/drs/dr12xx.cpp

 
 #if __cplusplus >= 201402L
   auto g(), h = 0; // expected-error {{function with deduced return type must be the only declaration in its group}}
   auto i = 0, j(); // expected-error {{function with deduced return type must be the only declaration in its group}}
   auto k(), l(); // expected-error {{function with deduced return type must be the only declaration in its group}}
 #endif
 }
 
+// dr1291: na
+
 namespace dr1295 { // dr1295: 4
   struct X {
     unsigned bitfield : 4;
   };
 
   X x = {1};
 
   unsigned const &r1 = static_cast<X &&>(x).bitfield; // expected-error 0-1{{C++11}}

clang/test/CXX/drs/dr23xx.cpp

 struct A {};
 const A a;
 
 // Now allowed to default-init B.
 struct B { const A a; };
 B b;
 
 }
+
+namespace dr2396 { // dr2396: no
+  template<typename T>
+  struct identity {
+    typedef T type;
+  };
+
+  struct A {
+    struct B;
+    operator B B::*();
+  };
+  struct B;
+
+  // FIXME: per P1787 "Calling a conversion function" example, all of the
+  // examples below are well-formed, with B resolving to A::B, but currently
+  // it's been resolved to dr2396::B. 
+
+  // void f(A a) { a.operator B B::*(); }            
+  // void g(A a) { a.operator decltype(B()) B::*(); }
+  // void g2(A a) { a.operator B decltype(B())::*(); }
+  // void h(A a) { a.operator identity<B>::type B::*(); }  
+  // void h2(A a) { a.operator B identity<B>::type::*(); } 
+}

clang/www/cxx_dr_status.html

<tr id="1290">
     <td>CD3</td>
     <td>Lifetime of the underlying array of an <TT>initializer_list</TT> member</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr id="1291">
     <td><a href="https://wg21.link/cwg1291">1291</a></td>
     <td>CD6</td>
     <td>Looking up a <I>conversion-type-id</I></td>
-    <td class="none" align="center">Unknown</td>
+    <td class="na" align="center">N/A</td>
   </tr>
   <tr id="1292">
     <td><a href="https://wg21.link/cwg1292">1292</a></td>
     <td>CD4</td>
     <td>Dependent calls with <I>braced-init-list</I>s containing a pack expansion</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr id="1293">
<tr class="open" id="2395">
     <td>drafting</td>
     <td>Parameters following a pack expansion</td>
     <td align="center">Not resolved</td>
   </tr>
   <tr id="2396">
     <td><a href="https://wg21.link/cwg2396">2396</a></td>
     <td>CD6</td>
     <td>Lookup of names in complex <I>conversion-type-id</I>s</td>
-    <td class="none" align="center">Unknown</td>
+    <td class="none" align="center">No</td>
   </tr>
   <tr id="2397">
     <td><a href="https://wg21.link/cwg2397">2397</a></td>
     <td>CD6</td>
     <td><TT>auto</TT> specifier for pointers and references to arrays</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr class="open" id="2398">