[clang] Add test for CWG472

[Endilll]

https://cplusplus.github.io/CWG/issues/472.html
It has drafting status, but I think CWG has reached consesus on the behavior.
Related: #16602

[llvmbot]

@llvm/pr-subscribers-clang

Changes

https://cplusplus.github.io/CWG/issues/472.html
It has drafting status, but I think CWG has reached consesus on the behavior.

---

Full diff: https://github.com/llvm/llvm-project/pull/67948.diff

2 Files Affected:

• (modified) clang/test/CXX/drs/dr4xx.cpp (+17)
• (modified) clang/www/cxx_dr_status.html (+1-1)

diff --git a/clang/test/CXX/drs/dr4xx.cpp b/clang/test/CXX/drs/dr4xx.cpp
index d8bdf49d0b2dde7..cc12e9f158061f8 100644
--- a/clang/test/CXX/drs/dr4xx.cpp
+++ b/clang/test/CXX/drs/dr4xx.cpp
@@ -924,6 +924,23 @@ namespace dr471 { // dr471: yes
   struct H : B, G { int f() { return n; } }; // expected-error {{private}}
 }
 
+namespace dr472 { // dr472: no drafting
+struct B {
+  int i; // #dr472-i-decl
+};
+struct I : protected B {}; // #dr472-inheritance
+struct D : public I {
+  void f(I *ip) {
+    ip->i = 0;
+    // expected-error@-1                {{'i' is a protected member of 'dr472::B'}}
+    // expected-note@#dr472-inheritance {{constrained by protected inheritance here}}
+    // expected-note@#dr472-i-decl      {{member is declared here}}
+    B *bp = ip;
+    bp->i = 5;
+  }
+};
+}
+
 namespace dr474 { // dr474: yes
   namespace N {
     struct S {
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index ee9712e9bab9949..b02f7ccfd371411 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -2871,7 +2871,7 @@ <h2 id="cxxdr">C++ defect report implementation status</h2>
     <td><a href="https://cplusplus.github.io/CWG/issues/472.html">472</a></td>
     <td>drafting</td>
     <td>Casting across protected inheritance</td>
-    <td align="center">Not resolved</td>
+    <td class="none" align="center">No</td>
   </tr>
   <tr id="473">
     <td><a href="https://cplusplus.github.io/CWG/issues/473.html">473</a></td>

[cor3ntin]

CC @zygoloid
In the proposed resolution, i do not understand why B* bp = n2p; should be ill-formed by virtue of being declared in P2

[shafik]

None of the implementations seem to agree with the resolution of the DR: https://godbolt.org/z/a7nEvW5Gr

[Endilll]

None of the implementations seem to agree with the resolution of the DR: https://godbolt.org/z/a7nEvW5Gr

It's definitely not the first time CWG goes against every major implementation with their DR resolution.

[Endilll]

In the proposed resolution, i do not understand why B* bp = n2p; should be ill-formed by virtue of being declared in P2

@cor3ntin Do you understand why http://eel.is/c++draft/class.protected#1 is there? (I'm trying to pick the best point to start explanation from)

[cor3ntin]

After additional archeology, I found the following minutes from Portland , 2012

Core issue 472: Casting across protected inheritance
_ Would the example work if P2 derived privately from N2?
_ ... Yes.. Hm, that was a good point.
redrafting.

Given that, I'd rather we don't try to read the tea leaves.
If we think this is important enough to fix, we should ping CWG.
But there seems to be some consistency across implementations, so I think we should punt work on this issue.

@zygoloid

[zygoloid]

None of the implementations seem to agree with the resolution of the DR: https://godbolt.org/z/a7nEvW5Gr

Yeah, I think this is a case where the wording is clear and everyone implements it, but it doesn't actually do the right thing. The example in the issue "ought to be" ill-formed, because as the issue points out, there's no reason to think that the N object is actually a base subobject of P, so access to its protected base B shouldn't be granted to a P object.

I think a rule even more similar to [class.protected] should be implemented: if we rely on a conversion from a class N to a class B, if N is a protected base class of B (if a public member of B would be a protected member of N), then additionally require that N is either C or a class derived from C (where C is the class granting access, as in [class.protected]).

I'd suggest we implement that as a warning, given that the standard is clear and other implementers accept.

In any case, this new testcase looks good to me, and would be good to add regardless of what CWG ends up deciding here (if they ever make a decision...).

[zygoloid]

For `"no drafting" status, can we say something different here? I think something like "Not resolved, probably no" would be better, given that we don't actually know what the resolution will be, and if it ends up resolved NAD then we actually do implement it correctly :-)

[Endilll]

Current state of things is my fault (I was the one who introduced no open, no drafting, and no review statuses). I've been pondering on a different idea recently: No*, and a pop-up saying something along the lines of Tentative; issue hasn't been resolved yet. Like cppreference does in their compiler support table. Seems less heavy for such a big table, but still provides details for those who are interested.

Another idea is for No to be a link to an issue on bug tracker instead of a pop-up.

It also worth mentioning that make_cxx_dr_status is strict with those unresolved statuses, and it yells every time status in a test doesn't match status in cwg_index.html.

[cor3ntin]

For `"no drafting" status, can we say something different here? I think something like "Not resolved, probably no" would be better, given that we don't actually know what the resolution will be, and if it ends up resolved NAD then we actually do implement it correctly :-)

I think that would make sense. Any opinion @AaronBallman ?

[AaronBallman]

I don't think we should read tea leaves on unresolved issues; WG21 and WG14 will change direction on unresolved issues sometimes and so documenting anything about how we compare to the proposed resolution runs a reasonably high risk of getting stale. I think it's fine to have tests to document how we currently behave (and then if the test breaks, it's a reminder to whoever made the change to go look at the current status of the issue). But maybe we should just leave these as Not Resolved and make no other claims?

Otherwise, the information I think that's most accurate is whether Clang does or does not exhibit the issue that was reported (when possible). At least that tells the user "if you think this is an issue, Clang has that behavior."

[cor3ntin]

Let's merge that and decided in #78836 what to do for the dr status page