Fix pre-existing copy pasta in variant/get_type.pass.cpp.

Use Jonathan's fix, which additionally validates the existence of the bug.

Update conditional: the bug was closed as a duplicate of a bug which has been fixed on master. Tag with the correct bug number, and disable the workaround for GCC 9.

In D60950#1474050, @mclow.lists wrote:

I think you failed to paste a bit into the description of this patch (after the first sentence, before the second).

Ping?

I merged this as r351148.

In D53763#1356356, @mclow.lists wrote:

I'm a bit concerned about the TEST_HAS_NO_SPACESHIP_OPERATOR and how it tracks with _LIBCPP_HAS_NO_SPACESHIP_OPERATOR, but I'm not going to hold this up for that.

Clarify use of numAllocs.

I'll put this explanation in the comments and push a change.

In D49118#1157438, @mclow.lists wrote:

I've conservatively hidden everything behind _LIBCPP_STD_VER > 17, although it could be made available in C++11 mode with some edits.

If we have a use for this in pre c++2a code, the libc++ convention would be to implement __common_reference that works most everywhere, and then have common_reference that only works > 17, but inherits from the ugly name.

That might be difficult in this case, because users can extend common_reference.

Qualify call to __invoke_constexpr in the definition of the Invocable concept.

In D46140#1086987, @EricWF wrote:

Jeez, this is weird. Having other STL maintainers review additions to libc++ :-)

In D46140#1083915, @lewissbaker wrote:

I have posted an updated version of the code here: https://gist.github.com/lewissbaker/38ba1d8a13e4fb0906559b7aa1c413d3

I'm still trying to figure out how to get the updated revision into this review.
I'm not familiar with Phabricator and it seems to want to create a new revision (review?) when I click the 'Update diff' button.
Does the updated diff need to be relative to the previous diff?
Any tips as to what I'm doing wrong are appreciated :)

This new-and-improved workaround - thanks to @lichray - is unintrusive enough that I can't imagine it being unnacceptable to anyone. I'm going to go ahead and check this in.

Better/simpler workaround from Zhihao.

This unconditional workaround addresses Marshall's concerns about the naked version test.

Make the workaround unconditional.

Hide the ugly version test in <__config>, define a slightly-more-meaningful macro _LIBCPP_WORKAROUND_CLANG_28385.

In D41048#950635, @mclow.lists wrote:

Ah - that was the factor I was missing.
The tests pass for me with -std=c++2a, but fail for std=c++17

Casey's original post said they fail with 2a, and I'm *still* not seeing that.

In D41048#950601, @mclow.lists wrote:

These tests don't fail for me. (using a clang I built two days ago)

In D41048#950424, @lebedev.ri wrote:

Test?

Don't unnecessarily fully qualify std::nullopt.

As the party who originally put this workaround in place, I'll happily certify that it never affected any platforms that anyone but we Microsofters care about. I'll take responsibility for any buildbot fallout - forward any nasty notices to me.

Looks good to me, although I am unfamiliar with your variant implementation. I won't approve the revision so that Eric will have to look at it, but consider me signed off.

Incorporate the libcxx test tree special_member_gen test into the std test, making my per-SMF triviality tests unnecessary.