This is an archive of the discontinued LLVM Phabricator instance.

[NFC][libc++] Removes sliceExpr friend.
ClosedPublic

Authored by Mordante on Apr 14 2023, 11:02 AM.

Details

Reviewers
EricWF
philnik
Group Reviewers
Restricted Project
Commits
rGd5193e34b81f: [NFC][libc++] Removes sliceExpr friend.
Summary

The class is never defined. This was discovered while validating modules
in libc++.

Diff Detail

Event Timeline

Mordante created this revision.Apr 14 2023, 11:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2023, 11:02 AM
Mordante requested review of this revision.Apr 14 2023, 11:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2023, 11:02 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
EricWF requested changes to this revision.Apr 14 2023, 1:23 PM
This revision now requires changes to proceed.Apr 14 2023, 1:23 PM
philnik accepted this revision.Apr 14 2023, 1:50 PM
philnik added a subscriber: philnik.

I think Eric wanted to approve, not block this.

This revision was not accepted when it landed; it landed in state Needs Revision.Apr 15 2023, 4:14 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Sorry, I meant to comment that this is likely a misspelling of __slice_expr. Though I don't know if it's needed, and the test coverage here is really poor. But I would rather change it to what the author likely intended it to be.

If we think there's no need for the friend declaration, then lets explain why we think it's unneeded in the commit message for archeology.

Because I suspect the addition of the friend declaration for __slice_expr without needing it points to a bit of unimplemented code.
But I don't think anybody want's to work on improving <valarray>?

If we think there's no need for the friend declaration, then lets explain why we think it's unneeded in the commit message for archeology.

Because I suspect the addition of the friend declaration for __slice_expr without needing it points to a bit of unimplemented code.

As discussed on Discord I'll revert and reland with a better commit message.

But I don't think anybody want's to work on improving <valarray>?

When I read about valarray the first time it sounded very interesting. Maybe when C++ has SIMD support it might be interesting to see whether that can be used for valarray. (I have hopes SIMD will be available in C++26.)