Skip to content

[clang] Add test for CWG472 #67948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jan 25, 2024
Merged

[clang] Add test for CWG472 #67948

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ad0df21
[clang] Add test for CWG472
Endilll Oct 2, 2023
23eadad
Merge remote-tracking branch 'upstream/main' into cwg472-test
Endilll Jan 10, 2024
605622e
Update expected directives
Endilll Jan 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions clang/test/CXX/drs/dr4xx.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1055,6 +1055,23 @@ namespace dr471 { // dr471: 2.8
// expected-note@#dr471-G-using {{declared private here}}
}

namespace dr472 { // dr472: no drafting
struct B {
int i; // #dr472-i
};
struct I : protected B {}; // #dr472-struct-I
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-struct-I {{constrained by protected inheritance here}}
// expected-note@#dr472-i {{member is declared here}}
B *bp = ip;
bp->i = 5;
}
};
}

namespace dr474 { // dr474: 3.4
namespace N {
struct S {
Expand Down
2 changes: 1 addition & 1 deletion clang/www/cxx_dr_status.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

</tr>
<tr id="473">
<td><a href="https://cplusplus.github.io/CWG/issues/473.html">473</a></td>
Expand Down