In D120951#3373293, @philnik wrote:

Doesn't this change make all of the tests with functions decorated with TEST_CONSTEXPR_AFTER_CXX20 undefined behavior, since it's undefined to have constexpr on a function that is never constexpr?

@EricWF How could this be undefined bahavior? All the tests are templated on the string, so it's possible to give them a constexpr string.

LGTM

LGTM % the check lambda stuff (which I won't insist on, anyway). Thanks!

Add libcpp-no-concepts. I'm surprised that there are platforms with libcpp-no-concepts yet without libcpp-has-no-incomplete-ranges! But OK.

In D121231#3368770, @EricWF wrote:

Please don't change this. Google uses this hook to change the behavior of string_view internally. We're working to get rid of the patch, but this helper function was specifically put in place to allow for the patch.

In D121213#3369677, @philnik wrote:

@EricWF And in what scenario would that change the ABI? If there are no copy- or move-constructors, then all are deleted by definition, and if there is one it isn't trivial.

Thanks, LGTM % comments. That was some quick turnaround time!

LGTM if CI is green. But do I understand correctly that this is still two orthogonal patches — one related to LIBCXX_ENABLE_ASSERTIONS, and one completely orthogonal to that in the benchmark code? Prefer to land in two separate git commits, just for hygiene.

LGTM%comments, and all the comments are pretty easy to deal with, I think.

it makes sense to run them even when the debug mode is disabled

Try a .sh.cpp test. This might be ready for review, although I assume I'll have to UNSUPPORTED a few platforms depending on what CI says.

LGTM if CI is green!

LGTM if CI is happy!

For now, skip asserting the number of comparisons in debug mode (attn @ldionne, this is relevant to your interests).
I think the GCC11 failure in https://buildkite.com/llvm-project/libcxx-ci/builds/9373 was a fluke, but let's see if it happens again.

I'm inclined to green-light this at this point. I haven't given it the fine-tooth-comb treatment this time, but it's been through enough rounds of review and I assume nothing that we covered earlier has regressed lately. However:

• CI is red for apparently multiple reasons; please make sure it becomes green.
• I'd like a second libc++ reviewer to take a look too.

Happy to take another look if anything major comes up in the second person's review.

Argh. Unsupport the new complexity test on C++11 because it lacks 1'000'000 literals, and I think the 's are nice enough that I don't feel like losing them. It seems unimaginable that C++03/11 would have different complexity characteristics from C++14/17/20/2b (and if they did, really, I'm not sure we'd care).

Sure, LGTM in principle. Please make sure you get a green CI run (or two!) before actually landing this, though. As you say above, that might take a while.

Oops, also add a release note. @ldionne LGTY?

Add complexity.pass.cpp for sort_heap and also for make_heap, since I've got those numbers already.
I thought of trying to make the assertions "fuzzy," but couldn't see a mathematically justifiable way of doing that, and besides, these numbers should never change unless they're deliberately being changed by someone who cares about these numbers! (As in this PR.)

I have no particular opinion on whether this is a good direction that will eventually lead somewhere useful, or just a random walk. No particular objection, either.

s/typedef/using/
s/_VSTD/std/
I claim this is ready to land. @ldionne?

LGTM now FWIW.

Thanks for working on this! This will be super useful — not really to working programmers ;) but in terms of checking boxes for C++17 conformance and finally getting to remove the experimental versions!

LGTM % comments, and the only significant comment affects the already-committed test for ranges::min_element. I think this is good to go, to get min and max back into parity; but then after that, they should both get some improved tests.

This is related to D119198: std::experimental::search works hand-in-hand with std::experimental::boyer_moore_searcher and company. We can't remove std::experimental::boyer_moore_searcher because we have not yet implemented C++17 std::boyer_moore_searcher
https://en.cppreference.com/w/cpp/utility/functional/boyer_moore_searcher
In this PR, @philnik observes that we could remove std::experimental::search, and just tell people to use std::experimental::boyer_moore_searcher with std::search instead.
In D119198, @jloser observed that we could remove std::experimental::default_searcher, and just tell people to use std::default_searcher with std::experimental::search instead.
But we can't remove all of the experimental searcher stuff in one fell swoop yet, because we haven't implemented the C++17 equivalents.

This is the sort of thing to alert libc++-vendors about, right?

LGTM%comment, but I'll ask for a second approver too.

Abandoning: The explicit ctors landed in D119894 and D120937; I don't care enough about the _LIBCPP_DEBUG_LEVEL == 2 changes to keep the rest of this open.

Undo a few diffs I'm not married to.

Push a lot of the non-functional diffs (and the ADL-proofing) to main in small separate commits, and then rebase.

Rebase, coalesce some repeated ifdefs, use unadorned constexpr in C++20-only codepaths

Fix GCC buildkite warning by removing unused typedefs.

Rebased after landing D119184. I'm no longer necessarily trying to land this note (it's not directly relevant to my interests anymore), but I'd like to show its CI as green before I abandon it. @rsmith would you like me to do something other than abandon this?

https://reviews.llvm.org/harbormaster/unit/view/2832828/ — filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104792 for what I consider a bogus GCC warning, but will fix anyway.

LGTM % nit: remove the word "proper", mainly for unnecessary-editorializing but also because I think the editorializing is wrong? Seems to me like the C locale "properly" shouldn't be using Unicode interpretations! :)

Rebased, poke CI one last time.
If this is green, imma land it.

LGTM

In D120896#3357193, @philnik wrote:

I'd want to avoid that, because after removing <experimental/algorithm> we could mechanically check for #include <algorithm> to make sure no one's going to include it directly again.