- User Since
- Dec 27 2014, 8:52 PM (430 w, 17 h)
Mar 11 2022
Mar 10 2022
LGTM % the check lambda stuff (which I won't insist on, anyway). Thanks!
Mar 9 2022
Add libcpp-no-concepts. I'm surprised that there are platforms with libcpp-no-concepts yet without libcpp-has-no-incomplete-ranges! But OK.
Mar 8 2022
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.
Mar 7 2022
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.
I claim this is ready to land. @ldionne?
LGTM now FWIW.
Mar 6 2022
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
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.
Mar 5 2022
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.
Mar 4 2022
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.
Mar 3 2022