This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Fix LWG3422 "Issues of seed_seq's constructors"
ClosedPublic

Authored by Quuxplusone on Jan 22 2022, 12:17 PM.

Details

Summary

https://cplusplus.github.io/LWG/issue3422

Also add a static_assert to check the "Mandates:" on the
iterator-pair constructor. Oddly, the InputIterator parameter
itself is merely preconditioned, not constrained, to satisfy the
input iterator requirements.

Also drive-by rename init to __init.

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.Jan 22 2022, 12:17 PM
Quuxplusone created this revision.
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptJan 22 2022, 12:17 PM
Mordante accepted this revision as: Mordante.Jan 23 2022, 4:51 AM

LGTM!

libcxx/include/__random/seed_seq.h
37–38

Please include __nullptr to make sure this is available.

Quuxplusone marked an inline comment as done.Jan 23 2022, 9:42 AM

@ldionne PTAL when you get a chance.

libcxx/include/__random/seed_seq.h
37–38

Actually this is under #ifndef _LIBCPP_CXX03_LANG so it should be fine. (I'm not sure we would #include <__nullptr> even if it weren't, but I've raised that tangent over on the Discord.)

Mordante added inline comments.Jan 23 2022, 10:23 AM
libcxx/include/__random/seed_seq.h
37–38

Good point. I think it would be good to do it when using C++03. So I retract my comment. So I'm happy with the current state of this patch.

ldionne accepted this revision.Jan 24 2022, 9:35 AM

LGTM with suggestions implemented.

libcxx/include/__random/seed_seq.h
36

Are we already testing this noexcept-ness? If not, please add a simple test for that.

82

Can we get a libc++ specific .verify.cpp test for this diagnostic?

This revision is now accepted and ready to land.Jan 24 2022, 9:35 AM
Quuxplusone marked 2 inline comments as done.
Quuxplusone edited the summary of this revision. (Show Details)

Add an ASSERT_NOEXCEPT.
Add a .verify.cpp test — but, yuck, it produces an extra error message after the nice one; anything we can/should do about this @ldionne?
Drive-by uglify init to __init; I don't see where the init name came from, and it's private, so I think it's fair game to uglify.

Add a .verify.cpp test — but, yuck, it produces an extra error message after the nice one; anything we can/should do about this @ldionne?

Yeah, that's annoying, but I think the solution you have right now is OK. Otherwise, in other places, I've also used something like this:

// This test checks that we static_assert inside std::atomic<T> when T
// is not trivially copyable, however Clang will sometimes emit additional
// errors while trying to instantiate the rest of std::atomic<T>.
// We silence those to make the test more robust.
// ADDITIONAL_COMPILE_FLAGS: -Xclang -verify-ignore-unexpected=error

Obviously you'd want to rephrase it not for atomic.