[clang] Add tests for DRs about complete-class context

[Endill]

Summary

P1787: The intent for CWG2335 (contra those of the older CWG1890, CWG1626, CWG1255, and CWG287) is supported by retaining the unrestricted forward lookup in complete-class contexts (despite current implementation behavior for non-templates).
Wording: The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise. [Drafting note: The plan for CWG2335 is to describe forbidden dependency cycles among the complete-class contexts of a class. — end drafting note] ([class.member.lookup]/4)

Complete-class context is described in [class.mem.general] p7 and p8. In this patch I add tests only for CWG issues that fall under current definition of complete-class context, because I'm not sure how CWG1255 and CWG287 are going to work. That's why I skip over them, but mark CWG1308 as superseded by CWG1330.

[shafik]

clang/test/CXX/drs/dr18xx.cpp

139

So this is still in drafting: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1890

We saw this in Issaquah and we felt like 1890 would probably be resolved once we resolve 2335: https://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#2335

I think we are leaning towards these being well-formed but we won't really know till it is resolved.

clang/test/CXX/drs/dr23xx.cpp

42

My comment on 1890 applies here as well.

CC @rsmith @aaron.ballman how should we handle DRs that are still in process? While we may think we know the direction it is going in, it could change.

So maybe we should avoid expressing an opinion on whether these are well-formed or not?

[shafik]

clang/test/CXX/drs/dr16xx.cpp

46

Since this is still open, should we be expressing an opinion on whether the examples are all well-formed or not?

[Endill]

clang/test/CXX/drs/dr23xx.cpp

42

I asked Aaron even before uploading the patch. His response was:

I think it's a judgement call -- if the CWG consensus seems like it makes a lot of sense, then I see no reason not to test them but maybe leave a FIXME comment about the issue technically being open still. If the CWG consensus doesn't make sense, that might be time to get on the reflectors and ask questions

Consensus documented in 2335 and drafting notes in P1787 that I quote in the summary made sense to me, so I published this patch. I can abandon it if there are fundamental issues with the them, rendering my judgement wrong.

[aaron.ballman]

clang/test/CXX/drs/dr23xx.cpp

42

I'd be curious to hear more thoughts on this.

In this particular case, this has been in drafting status since 2017, but the final comments on the open issue are:

Notes from the June, 2018 meeting:

The consensus of CWG was to treat templates and classes the same by "instantiating" delayed-parse regions when they are needed instead of at the end of the class.

See also issue 1890.

which seemed sufficiently firm in direction to warrant testing the behavior. I think any open DR being tested is subject to change in Clang and should continue to be documented in cxx_dr_status.html as "not resolved", though (so if CWG does make a change, we can still react to it without having promised the current behavior to users).

[Endill]

clang/test/CXX/drs/dr23xx.cpp

42

As a recap, in D138901 I updated make_cxx_dr_status script, so that it can take into account unresolved issues. Precedents were 2565 and 2628, which resorted to editing cxx_dr_status.html manually. Script now make sure that open or drafting bit in the comment matches status from the official page, throwing an exception otherwise.

[shafik]

clang/test/CXX/drs/dr23xx.cpp

42

I think documenting this is important.

What Aaron says makes sense to me, I just find the current comment all of the examples are well-formed. feels like a promise even though in the status page we may say not resolved.

I feel like the wording should be more cautious, maybe more like Current consensus is that the examples are well-formed.

[Endill]

Weaken the FIXME wording per Shafik's suggestion

clang/test/CXX/drs/dr13xx.cpp

 
 void caller() {
   // This should not be ambiguous, the 2nd overload is better.
   f({1, 2, 3});
 }
 #endif // __cplusplus >= 201103L
 } // namespace dr1307
 
+// dr1308: sup 1330
+
 namespace dr1310 { // dr1310: 5
   struct S {} * sp = new S::S; // expected-error {{qualified reference to 'S' is a constructor name}}
   void f() {
     S::S(a); // expected-error {{qualified reference to 'S' is a constructor name}}
   }
   struct T { int n; typedef int U; typedef T V; };
   int k = T().T::T::n;
   T::V v;

clang/test/CXX/drs/dr16xx.cpp

 
 namespace dr1611 { // dr1611: dup 1658
   struct A { A(int); };
   struct B : virtual A { virtual void f() = 0; };
   struct C : B { C() : A(0) {} void f(); };
   C c;
 }
 
+namespace dr1626 { // dr1626: no open
+// FIXME: current consensus for CWG2335 is that the examples are well-formed.
+#if __cplusplus >= 201103L
+namespace ex1 {
+template <typename T> struct C {
+  template <typename T2> static constexpr bool _S_chk() { return false; }
+  static const bool __value = _S_chk<int>();
+};
+template struct C<double>;
+} // namespace ex1
+
+namespace ex2 {
+struct C {
+  static constexpr bool _S_chk() { return false; }
+  static const bool __value = _S_chk();
+  // expected-error@-1 {{in-class initializer for static data member is not a constant expression}}
+};
+C c;
+} // namespace ex2
+#endif
+} // namespace dr1626
+
 namespace dr1631 {  // dr1631: 3.7
 #if __cplusplus >= 201103L
   // Incorrect overload resolution for single-element initializer-list
 
   struct A { int a[1]; };
   struct B { B(int); };
   void f(B, int);
   void f(B, int, int = 0);

clang/test/CXX/drs/dr18xx.cpp

namespace dr1881 { // dr1881: 7
   static_assert(!__is_standard_layout(B), "");
 
   struct C { int : 0; };
   struct D : C { int : 0; };
   static_assert(__is_standard_layout(C), "");
   static_assert(!__is_standard_layout(D), "");
 }
 
+namespace dr1890 { // dr1890: no drafting
+// FIXME: current consensus for CWG2335 is that the examples are well-formed.
+namespace ex1 {
+#if __cplusplus >= 201402L
+struct A {
+  struct B {
+    auto foo() { return 0; }
+  };
+  decltype(B().foo()) x;
+  // expected-error@-1 {{function 'foo' with deduced return type cannot be used before it is defined}}
+  // expected-note@-4 {{'foo' declared here}}
+};
+#endif
+} // namespace ex1
+
+namespace ex2 {
+#if __cplusplus >= 201103L
+struct Bar {
+  struct Baz {
+    int a = 0;
+  };
+  static_assert(__is_constructible(Baz), "");
+  // expected-error@-1 {{static assertion failed}}
+};
+#endif
+} // namespace ex2
+} // namespace dr1890
+
 void dr1891() { // dr1891: 4
 #if __cplusplus >= 201103L
   int n;
   auto a = []{}; // expected-note 0-4{{}}
   auto b = [=]{ return n; }; // expected-note 0-4{{}}
   typedef decltype(a) A;
   typedef decltype(b) B;
 

clang/test/CXX/drs/dr23xx.cpp

void g() {
   f(D{});
   f(F{}); // expected-error {{ambiguous conversion from derived class}}
 }
 } //namespace dr2303
 #endif
 
 // dr2331: na
 
+namespace dr2335 { // dr2335: no drafting
+// FIXME: current consensus is that the examples are well-formed.
+#if __cplusplus >= 201402L
+namespace ex1 {
+template <class...> struct partition_indices {
+  static auto compute_right() {}
+  static constexpr auto right = compute_right;
+};
+template struct partition_indices<int>;
+} // namespace ex1
+
+namespace ex2 {
+template <int> struct X {};
+template <class T> struct partition_indices {
+  static auto compute_right() { return X<I>(); }
+  static constexpr auto right = compute_right;
+  static constexpr int I = sizeof(T);
+  // expected-error@-3 {{no member 'I' in 'dr2335::ex2::partition_indices<int>'; it has not yet been instantiated}}
+  // expected-note@-3 {{in instantiation of member function 'dr2335::ex2::partition_indices<int>::compute_right' requested here}}
+  // expected-note@+3 {{in instantiation of template class 'dr2335::ex2::partition_indices<int>' requested here}}
+  // expected-note@-4 {{not-yet-instantiated member is declared here}}
+};
+template struct partition_indices<int>;
+} // namespace ex2
+
+namespace ex3 {
+struct partition_indices {
+  static auto compute_right() {}
+  static constexpr auto right = compute_right;
+  // expected-error@-1 {{function 'compute_right' with deduced return type cannot be used before it is defined}}
+  // expected-note@-3 {{'compute_right' declared here}}
+  // expected-error@-3 {{declaration of variable 'right' with deduced type 'const auto' requires an initializer}}
+};
+} // namespace ex3
+#endif
+} // namespace dr2335
+
 #if __cplusplus >= 201103L
 namespace dr2338 { // dr2338: 12
 namespace B {
 enum E : bool { Zero, One };
 static_assert((int)(E)2 == 1, "");
 } // namespace B
 namespace D {
 enum class E : bool { Zero, One };

clang/www/cxx_dr_status.html

<tr id="436">
     <td>CD1</td>
     <td>Problem in example in 9.6 paragraph 4</td>
     <td class="full" align="center">Yes</td>
   </tr>
   <tr id="437">
     <td><a href="https://cplusplus.github.io/CWG/issues/437.html">437</a></td>
     <td>CD1</td>
     <td>Is type of class allowed in member function exception specification?</td>
-    <td class="none" align="center">Superseded by <a href="#1308">1308</a></td>
+    <td class="full" align="center">Superseded by <a href="#1308">1308</a></td>
   </tr>
   <tr id="438">
     <td><a href="https://cplusplus.github.io/CWG/issues/438.html">438</a></td>
     <td>CD2</td>
     <td>Possible flaw in wording for multiple accesses to object between sequence points</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr id="439">
<tr id="1307">
     <td>C++14</td>
     <td>Overload resolution based on size of array <I>initializer-list</I></td>
     <td class="full" align="center">Clang 14</td>
   </tr>
   <tr id="1308">
     <td><a href="https://cplusplus.github.io/CWG/issues/1308.html">1308</a></td>
     <td>CD3</td>
     <td>Completeness of class type within an <I>exception-specification</I></td>
-    <td class="none" align="center">Unknown</td>
+    <td class="full" align="center">Superseded by <a href="#1330">1330</a></td>
   </tr>
   <tr id="1309">
     <td><a href="https://cplusplus.github.io/CWG/issues/1309.html">1309</a></td>
     <td>CD4</td>
     <td>Incorrect note regarding lookup of a member of the current instantiation</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr id="1310">
<tr class="open" id="1625">
     <td>open</td>
     <td>Adding spaces between tokens in stringizing</td>
     <td align="center">Not resolved</td>
   </tr>
   <tr class="open" id="1626">
     <td><a href="https://cplusplus.github.io/CWG/issues/1626.html">1626</a></td>
     <td>open</td>
     <td><TT>constexpr</TT> member functions in <I>brace-or-equal-initializer</I>s</td>
-    <td align="center">Not resolved</td>
+    <td class="none" align="center">No</td>
   </tr>
   <tr id="1627">
     <td><a href="https://cplusplus.github.io/CWG/issues/1627.html">1627</a></td>
     <td>NAD</td>
     <td>Agreement of dependent <TT>alignas</TT> specifiers</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr class="open" id="1628">
<tr class="open" id="1889">
     <td>drafting</td>
     <td>Unclear effect of <TT>#pragma</TT> on conformance</td>
     <td align="center">Not resolved</td>
   </tr>
   <tr class="open" id="1890">
     <td><a href="https://cplusplus.github.io/CWG/issues/1890.html">1890</a></td>
     <td>drafting</td>
     <td>Member type depending on definition of member function</td>
-    <td align="center">Not resolved</td>
+    <td class="none" align="center">No</td>
   </tr>
   <tr id="1891">
     <td><a href="https://cplusplus.github.io/CWG/issues/1891.html">1891</a></td>
     <td>CD4</td>
     <td>Move constructor/assignment for closure class</td>
     <td class="full" align="center">Clang 4</td>
   </tr>
   <tr id="1892">
<tr class="open" id="2334">
     <td>open</td>
     <td>Creation of objects by <TT>typeid</TT></td>
     <td align="center">Not resolved</td>
   </tr>
   <tr class="open" id="2335">
     <td><a href="https://cplusplus.github.io/CWG/issues/2335.html">2335</a></td>
     <td>drafting</td>
     <td>Deduced return types vs member types</td>
-    <td align="center">Not resolved</td>
+    <td class="none" align="center">No</td>
   </tr>
   <tr id="2336">
     <td><a href="https://cplusplus.github.io/CWG/issues/2336.html">2336</a></td>
     <td>CD5</td>
     <td>Destructor characteristics vs potentially-constructed subobjects</td>
     <td class="none" align="center">Unknown</td>
   </tr>
   <tr class="open" id="2337">