[clang] Add test for CWG36

[cor3ntin]

Could you make a separate pull request for updating the core issue list (I didn't know it had been updated recently)?
Or, i think you could commit the update of the core issue list directly (do you have commit rights?) and then work on the DR.

[Endill]

Sure, I'll update core issue list in a separate diff.
I don't have commit rights, but I have a commit merged (just one). Does it make me eligible for that?

[aaron.ballman]

In D138822#3954104, @Endill wrote:

Sure, I'll update core issue list in a separate diff.

Thanks!

I don't have commit rights, but I have a commit merged (just one). Does it make me eligible for that?

Not quite yet but I'm guessing by the time we're getting started with accepting these tests we'll have you ask for commit privileges. For the moment, I'd recommend making a separate patch and uploading it for (what should be a very quick) review and one of us can land that for you.

[erichkeane]

BTW, I suspect you're close enough to ask for commit rights, and I'd prefer to not have to commit too many things for you, so please go through this procedure: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

[Endill]

Incorporate D138835

[Endill]

Sorry, I messed up diff update

[Endill]

Incorporate D138835 (correctly this time around)

[aaron.ballman]

Adding Hubert for his C++ conformance opinion.

clang/test/CXX/drs/dr0xx.cpp

454

It took me a while to convince myself, but yes, I agree that Clang seems to implement the DR. I had to go back to P1787 to figure that out, but the key bit of new wording is:

If a declaration named by a using-declaration that inhabits the target scope of another declaration potentially conflicts with it ([basic.scope.scope]) and either is reachable from the other, the program is ill-formed. If two declarations named by using-declaration⁠s that inhabit the same scope potentially conflict, either is reachable from the other, and they do not both declare functions or function templates, the program is ill-formed.

[shafik]

clang/test/CXX/drs/dr0xx.cpp

454

It makes sense to me as well, although it would have been nice to have some examples in standard to reflect this as well.

[Endill]

@aaron.ballman Following example of other DR tests, I was reluctant to add relevant comments, e.g. wording. But I can provide it going forward or even update this patch.

[aaron.ballman]

In D138822#3957395, @Endill wrote:

@aaron.ballman Following example of other DR tests, I was reluctant to add relevant comments, e.g. wording. But I can provide it going forward or even update this patch.

No worries, you didn't do anything wrong. I was grousing about WG21 leaving the DR in a state where it's not clear *how* it was resolved without going back to a very complex omnibus paper.

[Endill]

Among the worst parts of this paper are references to mailing list and EDG wiki, which I don't have access to. But I still managed to dig everything up, and ready to explain if requested. No tests were copied blindly from issues.

[aaron.ballman]

In D138822#3957459, @Endill wrote:

Among the worst parts of this paper are references to mailing list and EDG wiki, which I don't have access to. But I still managed to dig everything up, and ready to explain if requested. No tests were copied blindly from issues.

Good to know, thank you! FWIW, if you need help getting references from the mailing list or the wiki, feel free to mention what you're after and one of us on the committee can see about tracking down the details.

[aaron.ballman]

Adding my explicit LG, but just personally instead of for the language wg. If we don't hear from anyone else in the next 1-2 days, I'd say this is safe to land.

[Endill]

Thank you!

FWIW, if you need help getting references from the mailing list or the wiki, feel free to mention what you're after and one of us on the committee can see about tracking down the details.

Do you mean creating an incomplete diff and asking here in the comments?

[aaron.ballman]

In D138822#3957503, @Endill wrote:

Thank you!

FWIW, if you need help getting references from the mailing list or the wiki, feel free to mention what you're after and one of us on the committee can see about tracking down the details.

Do you mean creating an incomplete diff and asking here in the comments?

That's one approach, but if you don't have a diff handy when the questions come up, you can also ask on Discourse/Discord/IRC or you can ask me directly via email.

[erichkeane]

clang/test/CXX/drs/dr0xx.cpp

489

As a nit, I prefer the 'notes' to live next to the error, and use a bookmark line-marker here. My issue is basically how we have no way of knowing (particularly in template code...) what this diagnoses.

I would also think a dependent example of this diagnostic would be useful.

[Endill]

Discord feels perfect to me for this kind of questions. What's left is to get past a broken bot for agreeing with code of conduct.

[Endill]

clang/test/CXX/drs/dr0xx.cpp

489

I would also think a dependent example of this diagnostic would be useful.

Do you mean something of this sort: using D<int>::i?

[erichkeane]

clang/test/CXX/drs/dr0xx.cpp

489

That is a good example too, but more a case where the using expression is dependent, so something like: using Struct<T>::i sorta thing

[Endill]

Add examples with dependent types, and rearrange using declarations to group errors and notes.

[Endill]

Get rid of unwanted changes supposedly caused by arc diff

[Endill]

clang/test/CXX/drs/dr0xx.cpp

489

I prefer the 'notes' to live next to the error

done

I would also think a dependent example of this diagnostic would be useful.

I'm not sure how you wanted it to interact with virtual bases, so I wrote examples both with virtual bases and without

use a bookmark line-marker here

While I'm sympathetic to your concern, and agree that bookmarks allow to order expected errors and notes in the order they would appear for user, searching for @# gives only 5 DR tests. If that's the direction we want DR tests to take, we should be explicit about this, because almost all existing tests have to be adjusted.

[aaron.ballman]

clang/test/CXX/drs/dr0xx.cpp

489

While I'm sympathetic to your concern, and agree that bookmarks allow to order expected errors and notes in the order they would appear for user, searching for @# gives only 5 DR tests. If that's the direction we want DR tests to take, we should be explicit about this, because almost all existing tests have to be adjusted.

FWIW, we don't have to adjust all the tests -- sometimes bookmarks make things more clear, other times they don't help all that much, and it's an equivalent test either way. My recommendation is to use bookmarks when you think they make sense to use or when a reviewer asks for one. Updating other tests can be done with NFC changes if someone sees a particular need.

[Endill]

clang/test/CXX/drs/dr0xx.cpp

489

FWIW, we don't have to adjust all the tests -- sometimes bookmarks make things more clear, other times they don't help all that much, and it's an equivalent test either way. My recommendation is to use bookmarks when you think they make sense to use or when a reviewer asks for one. Updating other tests can be done with NFC changes if someone sees a particular need.

The concern about expected-note comments scattered across a test seems applicable to any test with more than one expected-warning or expected-error. If maintainers agree that it should be addressed with bookmarks, I'll update this patch, and make NFC commits to fix existing tests.

What I'd like to avoid is introducing even more inconsistencies into DR tests. Until very recently (before tests for 2565 and 2628), bookmarks have been used only under #if __cplusplus, where you don't have any other straightforward option (e.g. dr100).

[aaron.ballman]

clang/test/CXX/drs/dr0xx.cpp

489

The concern about expected-note comments scattered across a test seems applicable to any test with more than one expected-warning or expected-error.

To me, it's less about the number of expected diagnostics and more about locality of the diagnostics. If the warning/error and note are only a few lines away from one another, I (personally) don't use bookmarks because the syntax is a bit novel, especially for newcomers. But if there is quite a bit of space between the warning/error and the note, then I like using bookmarks because it helps me to pair the note with the diagnostic. e.g.,

// To me, this is fine.
int note_goes_here; // expected-note {{the bad thing was declared here}}
foo(note_goes_here); // expected-warning {{something went wrong with this argument}}

// To me, this is also fine.
int note_goes_here; // #bad_thing
// ... lots of code ...
// ... even more code ...
foo(note_goes_here); // expected-warning {{something went wrong with this argument}} \
                        expected-note@#bad_thing {{the bad thing was declared here}}

but it's a value judgment as to what "quite a bit of space" is and whether using the bookmark improves the test or not. So:

// To me, this is not really a good use of bookmarks.
int note_goes_here; // #bad_thing
foo(note_goes_here); // expected-warning {{something went wrong with this argument}} \
                        expected-note@#bad_thing {{the bad thing was declared here}}

What I'd like to avoid is introducing even more inconsistencies into DR tests. Until very recently (before tests for 2565 and 2628), bookmarks have been used only under #if __cplusplus, where you don't have any other straightforward option (e.g. dr100).

I'm not at all worried about inconsistency in how we surface the expected comments. Bookmarks are a newer and somewhat under-utilized feature of the diagnostic verifier. We're going to have a lot of tests that predate the ability to use that feature, so inconsistency is inevitable.

In this particular case, I don't think the bookmarks are all that helpful because the note and the diagnostic are adjacent in the code. @erichkeane, WDYT?

[erichkeane]

clang/test/CXX/drs/dr0xx.cpp

489

So FWIW, I'm the one pushing to have us use bookmarks more often, which others haven't done in the past. I found that while reviewing/going through a bunch of template code for concepts that the tests were 100% unreadable because bookmarks weren't used.

As far as readability/beginner friendliness: Everyone I've suggested these to in the past has been a fan of them, and had no problem figuring them out once sent to the documentation page.

In this case, as Aaron said, it is perhaps not necessary, but I'm still a fan of keeping them in the order they are emitted if at all possible. If it was up to me, VerifyDiagnosticsConsumer would enforce diagnostic-note ordering.

clang/test/CXX/drs/dr0xx.cpp

 // RUN: %clang_cc1 -std=c++98 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -Wno-bind-to-temporary-copy
 // RUN: %clang_cc1 -std=c++11 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -triple %itanium_abi_triple
 // RUN: %clang_cc1 -std=c++14 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -triple %itanium_abi_triple
 // RUN: %clang_cc1 -std=c++17 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -triple %itanium_abi_triple
+// RUN: %clang_cc1 -std=c++20 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -triple %itanium_abi_triple
+// RUN: %clang_cc1 -std=c++2b %s -verify -fexceptions -fcxx-exceptions -pedantic-errors -triple %itanium_abi_triple
 
 namespace dr1 { // dr1: no
   namespace X { extern "C" void dr1_f(int a = 1); }
   namespace Y { extern "C" void dr1_f(int a = 1); }
   using X::dr1_f; using Y::dr1_f;
   void g() {
     dr1_f(0);
     // FIXME: This should be rejected, due to the ambiguous default argument.
namespace member {
     struct X { template<typename> static Y f(); };
     int m = Q() + X().f<int>; // ok
     int n = Q() + (&(X().f<int>)); // ok
   }
 }
 
 // dr34: na
 // dr35: dup 178
+
+namespace dr36 { // dr36: yes
+namespace example1 {
+  namespace A {
+    int i;
+  }
+  
+  namespace A1 {
+    using A::i;
+    using A::i;
+  }
+  
+  void f()
+  {
+    using A::i;
+    using A::i;
+  }
+}
+
+namespace example2 {
+  struct A
+  {
+    int i;
+    static int j;
+  };
+
+  struct B : A { };
+  struct C : A { };
+
+  struct D : virtual B, virtual C
+  {
+    using B::i; // expected-note {{previous using declaration}}
+    using C::i; // expected-note {{previous using declaration}}
+    using B::j; // expected-note {{previous using declaration}}
+    using C::j; // expected-note {{previous using declaration}}
+
+    using B::i; // expected-error {{redeclaration of using declaration}}
+    using C::i; // expected-error {{redeclaration of using declaration}}
+    using B::j; // expected-error {{redeclaration of using declaration}}
+    using C::j; // expected-error {{redeclaration of using declaration}}
+  };
+}
+}
+
 // dr37: sup 475
 
 namespace dr38 { // dr38: yes
   template<typename T> struct X {};
   template<typename T> X<T> operator+(X<T> a, X<T> b) { return a; }
   template X<int> operator+<int>(X<int>, X<int>);
 }
 
#if __cplusplus >= 201103L
   enum E2 { E2_0 = 0, E2_m1 = -1 };
   struct X { E1 e1 : 1; E2 e2 : 1; };
   static_assert(X{E1_1, E2_m1}.e1 == 1, "");
   static_assert(X{E1_1, E2_m1}.e2 == -1, "");
 #endif
 }
 
 namespace dr59 { // dr59: yes
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wdeprecated-volatile"
   template<typename T> struct convert_to { operator T() const; };
   struct A {}; // expected-note 5+{{candidate}}
   struct B : A {}; // expected-note 0+{{candidate}}
 
   A a1 = convert_to<A>();
   A a2 = convert_to<A&>();
   A a3 = convert_to<const A>();
   A a4 = convert_to<const volatile A>();
#endif
   A c4 = convert_to<const volatile B>(); // expected-error {{no viable}}
   A c5 = convert_to<const volatile B&>(); // expected-error {{no viable}}
 
   int n1 = convert_to<int>();
   int n2 = convert_to<int&>();
   int n3 = convert_to<const int>();
   int n4 = convert_to<const volatile int>();
   int n5 = convert_to<const volatile int&>();
+#pragma clang diagnostic pop
 }
 
 namespace dr60 { // dr60: yes
   void f(int &);
   int &f(...);
   const int k = 0;
   int &n = f(k);
 }

clang/www/cxx_dr_status.html

<tr id="35">
     <td>TC1</td>
     <td>Definition of default-initialization</td>
     <td class="full" align="center">Duplicate of <a href="#178">178</a></td>
   </tr>
   <tr id="36">
     <td><a href="https://wg21.link/cwg36">36</a></td>
     <td>CD6</td>
     <td><I>using-declaration</I>s in multiple-declaration contexts</td>
-    <td class="none" align="center">Unknown</td>
+    <td class="full" align="center">Yes</td>
   </tr>
   <tr id="37">
     <td><a href="https://wg21.link/cwg37">37</a></td>
     <td>NAD</td>
     <td>When is uncaught_exception() true?</td>
     <td class="none" align="center">Superseded by <a href="#475">475</a></td>
   </tr>
   <tr id="38">