Page MenuHomePhabricator

huixie90 (Hui)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 7 2022, 6:10 AM (30 w, 2 d)

Recent Activity

Thu, Aug 4

huixie90 accepted D130835: [libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`..

LGTM after Louis's comments are addressed

Thu, Aug 4, 12:15 AM · Restricted Project, Restricted Project

Fri, Jul 29

huixie90 committed rG72f57e3a30d5: [libc++][ranges] implement `std::ranges::unique{_copy}` (authored by huixie90).
[libc++][ranges] implement `std::ranges::unique{_copy}`
Fri, Jul 29, 12:29 AM · Restricted Project, Restricted Project
huixie90 closed D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.
Fri, Jul 29, 12:28 AM · Restricted Project, Restricted Project

Thu, Jul 28

huixie90 updated subscribers of D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.

Also thanks to @Quuxplusone who contacted me and spotted that I missed an if constexpr in ranges::unique_copy and an unnecessary next call in adjacent_find

Thu, Jul 28, 1:14 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.

address review feedback

Thu, Jul 28, 1:05 PM · Restricted Project, Restricted Project
huixie90 published D130599: [libc++][ranges] Implement `ranges::remove_copy{, _if}`. for review.
Thu, Jul 28, 8:56 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.

got patch number wrong

Thu, Jul 28, 8:52 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.
  • finalise ranges::remove_copy{_if}
Thu, Jul 28, 8:50 AM · Restricted Project, Restricted Project
huixie90 added inline comments to D130532: [libc++][ranges] Implement `std::ranges::partial_sort_copy`..
Thu, Jul 28, 4:04 AM · Restricted Project, Restricted Project
huixie90 committed rG8a61749f767e: [libc++][ranges] implement `std::ranges::inplace_merge` (authored by huixie90).
[libc++][ranges] implement `std::ranges::inplace_merge`
Thu, Jul 28, 12:40 AM · Restricted Project, Restricted Project
huixie90 closed D130627: [libc++][ranges] implement `std::ranges::inplace_merge`.
Thu, Jul 28, 12:39 AM · Restricted Project, Restricted Project, Restricted Project

Wed, Jul 27

huixie90 updated the diff for D130627: [libc++][ranges] implement `std::ranges::inplace_merge`.

address comments

Wed, Jul 27, 3:35 PM · Restricted Project, Restricted Project, Restricted Project
huixie90 updated the diff for D130627: [libc++][ranges] implement `std::ranges::inplace_merge`.

add newline

Wed, Jul 27, 2:58 PM · Restricted Project, Restricted Project, Restricted Project
huixie90 updated the diff for D130627: [libc++][ranges] implement `std::ranges::inplace_merge`.

address review feedback

Wed, Jul 27, 2:53 PM · Restricted Project, Restricted Project, Restricted Project
huixie90 accepted D130538: [libc++] Make `_IterOps::__iter_move` more similar to `std::ranges::iter_move`..
Wed, Jul 27, 12:25 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.

rebase

Wed, Jul 27, 11:51 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D130627: [libc++][ranges] implement `std::ranges::inplace_merge`.

fix CI

Wed, Jul 27, 11:42 AM · Restricted Project, Restricted Project, Restricted Project
huixie90 published D130627: [libc++][ranges] implement `std::ranges::inplace_merge` for review.
Wed, Jul 27, 8:26 AM · Restricted Project, Restricted Project, Restricted Project
huixie90 added inline comments to D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.
Wed, Jul 27, 5:52 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D130404: [libc++][ranges] implement `std::ranges::unique{_copy}`.

addresss feedback

Wed, Jul 27, 5:52 AM · Restricted Project, Restricted Project

Tue, Jul 26

huixie90 added a comment to D130515: [libc++][ranges] Make sure all range algorithms support differing projection types:.

The fix looks good to me and I think we should delete the overload __make_projected_comp(__comp, __proj1, __proj2) and replace all the usages with hand coded std::invoke

Without this test, I'd agree. With the test, however, I think the benefits outweigh the drawbacks. If an algorithm switches the comparison order, this test will break. However, make_projected_comp not only reduces on boilerplate and keeps most internal algorithms unaware of projections, it also allows passing in the original comparator without modification and "eliding" identity when possible.

Tue, Jul 26, 4:02 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..
Tue, Jul 26, 3:41 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130547: [libc++][ranges] Implement `ranges::is_heap{,_until}`..
Tue, Jul 26, 3:33 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130552: [libc++][ranges] Implement `ranges::generate{,_n}`..
Tue, Jul 26, 3:22 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130595: [libc++][doc] Updates status documents..
Tue, Jul 26, 3:10 PM · Restricted Project, Restricted Project
huixie90 accepted D130595: [libc++][doc] Updates status documents..
Tue, Jul 26, 1:28 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130532: [libc++][ranges] Implement `std::ranges::partial_sort_copy`..
Tue, Jul 26, 1:25 PM · Restricted Project, Restricted Project
huixie90 accepted D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..
Tue, Jul 26, 1:15 PM · Restricted Project, Restricted Project
huixie90 accepted D130547: [libc++][ranges] Implement `ranges::is_heap{,_until}`..

Almost LGTM thanks!

Tue, Jul 26, 7:34 AM · Restricted Project, Restricted Project
huixie90 accepted D130552: [libc++][ranges] Implement `ranges::generate{,_n}`..
Tue, Jul 26, 6:09 AM · Restricted Project, Restricted Project
huixie90 accepted D130532: [libc++][ranges] Implement `std::ranges::partial_sort_copy`..
Tue, Jul 26, 5:59 AM · Restricted Project, Restricted Project
huixie90 added a comment to D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..

LGMT

Tue, Jul 26, 4:17 AM · Restricted Project, Restricted Project
huixie90 accepted D130515: [libc++][ranges] Make sure all range algorithms support differing projection types:.

This is a definitely needed fix. Whether or not to fix set_* algorithms in the same patch should not block this patch.

Tue, Jul 26, 3:53 AM · Restricted Project, Restricted Project
huixie90 added a comment to D129823: [libc++][ranges] Make range algorithms support proxy iterators.

@alexfh @jgorbe @rupprecht Thank you for the additional details! I believe the analysis by @huixie90 is spot on and have prepared a patch based on it: https://reviews.llvm.org/D130538
Can you try out the patch to see if it resolves the issue you're seeing? It does fix the repro case for me.

Thanks! Unfortunately, it just changes the failure that we now see from a crash to a weird runtime failure; incorrectly sorted results, I assume.

I have an alternative change to fix the UB and return varlen_element & instead of varlen_element (isn't that the eventual fix we should do anyway?), and initial tests seem to be passing now. I'm not sure what D130538 is missing.

Tue, Jul 26, 3:51 AM · Restricted Project, Restricted Project

Mon, Jul 25

huixie90 added a comment to D129823: [libc++][ranges] Make range algorithms support proxy iterators.

Some more information about the problem. The stack trace looks like follows. The problem manifests as an ASan out of memory error because the move constructor in varlen_sort.h:59 is getting incorrect data and it's trying to allocate an absurdly big amount of memory.

==7713==ERROR: AddressSanitizer: out of memory: allocator is trying to allocate 0xc5600000e4e bytes
    #0 0x55deed3caedd in operator new[](unsigned long) third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:98:3
    #1 0x55deed6e733c in varlen_element MYSQLSRCHOME/include/varlen_sort.h:59:17
    #2 0x55deed6e733c in bool std::__u::__insertion_sort_incomplete<void varlen_sort<unsigned char, DsMrr_impl::dsmrr_fill_buffer()::$_3>(unsigned char*, unsigned char*, unsigned long, DsMrr_impl::dsmrr_fill_buffer()::$_3)::'lambda'(varlen_element const&, varlen_element const&)&, varlen_iterator>(DsMrr_impl::dsmrr_fill_buffer()::$_3, DsMrr_impl::dsmrr_fill_buffer()::$_3, unsigned char) third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__algorithm/sort.h:373:18
    #3 0x55deed6e4fcd in void std::__u::__introsort<std::__u::_ClassicAlgPolicy, void varlen_sort<unsigned char, DsMrr_impl::dsmrr_fill_buffer()::$_3>(unsigned char*, unsigned char*, unsigned long, DsMrr_impl::dsmrr_fill_buffer()::$_3)::'lambda'(varlen_element const&, varlen_element const&)&, varlen_iterator>(varlen_iterator, varlen_iterator, DsMrr_impl::dsmrr_fill_buffer()::$_3, std::__u::iterator_traits<varlen_iterator>::difference_type) third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__algorithm/sort.h:575:19
    #4 0x55deed6db70b in __sort<(lambda at MYSQLSRCHOME/include/varlen_sort.h:199:13) &, varlen_iterator> third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__algorithm/sort.h:627:3
    #5 0x55deed6db70b in __sort_impl<std::__u::_ClassicAlgPolicy, varlen_iterator, (lambda at MYSQLSRCHOME/include/varlen_sort.h:199:13)> third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__algorithm/sort.h:687:5
    #6 0x55deed6db70b in sort<varlen_iterator, (lambda at MYSQLSRCHOME/include/varlen_sort.h:199:13)> third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__algorithm/sort.h:694:3
    #7 0x55deed6db70b in varlen_sort<unsigned char, (lambda at MYSQLSRCHOME/sql/handler.cc:6738:7)> MYSQLSRCHOME/include/varlen_sort.h:197:3
    #8 0x55deed6db70b in DsMrr_impl::dsmrr_fill_buffer() MYSQLSRCHOME/sql/handler.cc:6736:3
    #9 0x55deed6da9c8 in DsMrr_impl::dsmrr_init(RANGE_SEQ_IF*, void*, unsigned int, unsigned int, HANDLER_BUFFER*) MYSQLSRCHOME/sql/handler.cc:6617:17
    #10 0x55deedf21bb6 in MultiRangeRowIterator::Init() MYSQLSRCHOME/sql/bka_iterator.cc:368:18
    #11 0x55deedf21100 in BKAIterator::ReadOuterRows() MYSQLSRCHOME/sql/bka_iterator.cc:228:22
    #12 0x55deedf2174a in BKAIterator::Read() MYSQLSRCHOME/sql/bka_iterator.cc:274:19
    #13 0x55deede3ed6b in Query_expression::ExecuteIteratorQuery(THD*) MYSQLSRCHOME/sql/sql_union.cc:1231:36
    #14 0x55deede3f4e4 in Query_expression::execute(THD*) MYSQLSRCHOME/sql/sql_union.cc:1284:10
    #15 0x55deedd5a4f6 in Sql_cmd_dml::execute_inner(THD*) MYSQLSRCHOME/sql/sql_select.cc:776:15
    #16 0x55deedd59381 in Sql_cmd_dml::execute(THD*) MYSQLSRCHOME/sql/sql_select.cc:574:7
    #17 0x55deedcb2863 in mysql_execute_command(THD*, bool) MYSQLSRCHOME/sql/sql_parse.cc:4438:29
    #18 0x55deedcae283 in dispatch_sql_command(THD*, Parser_state*) MYSQLSRCHOME/sql/sql_parse.cc:5037:19
    #19 0x55deedcaac9c in dispatch_command(THD*, COM_DATA const*, enum_server_command) MYSQLSRCHOME/sql/sql_parse.cc:1863:7
    #20 0x55deedcacd8b in do_command(THD*) MYSQLSRCHOME/sql/sql_parse.cc:1342:18
    #21 0x55deed3fe4f3 in handle_connection(void*) MYSQLSRCHOME/sql/conn_handler/connection_handler_per_thread.cc:310:13
    #22 0x55def2434649 in pfs_spawn_thread(void*) MYSQLSRCHOME/storage/perfschema/pfs.cc:2905:3
    #23 0x7f6af0285b54 in start_thread (/usr/grte/v5/lib64/libpthread.so.0+0xbb54) (BuildId: 64752de50ebd1a108f4b3f8d0d7e1a13)

sort.h:373 does

	      value_type __t(_Ops::__iter_move(__i));

When reaching this line the value of __i is correct. However, after the call to __iter_move, the varlen_element move constructor (source) gets incorrect values.

I've managed to get the test to pass by replacing occurrences of _Ops::__iter_move(iter) back to _VSTD::move(*iter) and I don't see anything particularly wrong with the affected mysql code so I suspect there's some remaining problem in __iter_move that hasn't been solved with the follow-up patches so far.

Mon, Jul 25, 6:10 PM · Restricted Project, Restricted Project
huixie90 added a comment to D130515: [libc++][ranges] Make sure all range algorithms support differing projection types:.

The fix looks good to me and I think we should delete the overload __make_projected_comp(__comp, __proj1, __proj2) and replace all the usages with hand coded std::invoke

Mon, Jul 25, 5:32 PM · Restricted Project, Restricted Project
huixie90 published D130404: [libc++][ranges] implement `std::ranges::unique{_copy}` for review.
Mon, Jul 25, 9:40 AM · Restricted Project, Restricted Project

Sat, Jul 23

huixie90 added a comment to D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..

My original test has some coverage (would fail on gcc). I am trying to figure out why clang passes the test. See this reproduction example (it is basically my original test plus making Reference destructor to set _i to be nullptr

That's exactly my experience with compiler warnings and tools like Asan -- all of them are essentially "best effort" and aren't reliable ("reliable" in the sense "guaranteed to catch 100% of issues"). In fact, when I did the first patch to fix the Chromium issue, Clang could see the dangling temporary in the original version of __iter_move (that returned a dangling value_type) but not in the version from the patch (that returned a dangling reference), even though both were equally UB and essentially the same issue. You encountered a very similar problem where GCC sees a lifetime issue while Clang doesn't. I'm sure there exist counterexamples where Clang would catch something that GCC cannot spot. The point is, these warnings aren't meant to validate that the code is correct -- while their presence almost always indicates a problem, their absence doesn't guarantee there is no problem. Asan similarly cannot catch all issues. To be clear, all these tools are very helpful, but should be used for their intended purpose and not to verify that code is correct.

However, the assertion assert(i==5) isn't triggered because of the Undefined Behaviour. The compiler doesn't even bother assert as i is just rubbish value.

The assertion isn't triggered because the program segfaults on the line that calls iter_move. Unfortunately, Godbolt output doesn't make it very clear, but 139 isn't the value of i, it's the return code of a program upon receiving sigsegv (11, which is the code of the signal, + 128).

From the perspective of the standard, the Godbolt program might be equivalently undefined compared to this patch, but in practice there is a very important difference -- the program dereferences this after the destructor has been run, while this patch doesn't.

To be clear, I would love to do it another way that doesn't require this sort of "this is technically undefined but works in practice" analysis. Unfortunately, I don't really see it. constexpr would be the perfect solution if it were not for the coverage problems. I think that tooling works best as complimentary, not the exclusive means of detecting this sort of issue.

There are some possible mitigations we could do as well. We can make sure this test runs without optimizations, we may restrict it to a certain compiler version if need be, and we could add a fail.cpp test to make sure it actually fails in practice (when encountering memory problems). I think this is overkill, personally, but wouldn't object if you feel strongly about this.

Sat, Jul 23, 12:00 PM · Restricted Project, Restricted Project
huixie90 added a comment to D128146: [libc++] Use uninitialized algorithms for vector.

@philnik , can you please help me understand what is going on with the original example posted by @bgraur ?

The fact is that the example compiled before this patch and failed with this patch. Even if the example is buggy, I still need to understand what the semantics were when it worked. Was it using the wrong ctor? Why did it change with this patch?

I'm seeing a number of tests failing with this patch, so understanding the example might give me a clue where to look.

Sat, Jul 23, 12:11 AM · Restricted Project, Restricted Project

Fri, Jul 22

huixie90 added a comment to D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..

I think this is good. But I'd like to clarify the idea behind it. IIUC, the idea is that

  • there is a global object pool of ptrs
  • the class's destructor removes this from the global pool
  • every operation assert this is inside the pool

But if the object destructor has been run, it is UB to call its member function. and since it is UB , those assert in theory is not guaranteed to run

Yes, it's true that this relies on undefined behavior. However, I think it's the pragmatic thing to do:

  • I can't think of a way to do this that avoids UB, because checking an object after its destructor has run is really the crux of the problem. constexpr checks are great in that regard but unfortunately won't give us full coverage as I mentioned in another comment. So it looks like our alternatives are either having checks that rely on UB or no checks at all (for some cases, like most of std::sort which is the motivating example);
  • I have manually confirmed that it works (in the sense that it does find actual lifetime issues). It would have found both the original bug that triggered the assertion in Chromium and the fact that the first patch with the fix still contained a dangling temporary;
  • I have deliberately written the lifetime checks so that they never dereference this (that's one of the reasons the cache is a static variable). In practice, I presume that member function calls translate to regular function calls with this as the first parameter (simplifying a little). Neither the function code nor the _value_ of the this pointer have a reason to become invalid after the destructor has run. Now, it's possible that some compiler optimization simply prevents the member function from being called since that is supposed to be impossible (for a valid program). I'm very skeptical this could happen in practice, and even if it does, it seems like the worst that could happen is that these tests would miss a lifetime bug. While that would be unfortunate, it's not significantly worse than the status quo which is no checks at all.

Of course, I'd be happy to rewrite this if there's a way to achieve the same or similar coverage without relying on undefined behavior. Unfortunately, I can't think of one -- if you have any ideas, I'm happy to discuss.

Fri, Jul 22, 3:20 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130321: [libc++][ranges] Implement `ranges::shuffle`..
Fri, Jul 22, 11:09 AM · Restricted Project, Restricted Project
huixie90 added a comment to D130321: [libc++][ranges] Implement `ranges::shuffle`..

LGTM

Fri, Jul 22, 11:03 AM · Restricted Project, Restricted Project
huixie90 added a comment to D130330: [libc++][NFC] Add checks for lifetime issues in classic algorithms..

I think this is good. But I'd like to clarify the idea behind it. IIUC, the idea is that

  • there is a global object pool of ptrs
  • the class's destructor removes this from the global pool
  • every operation assert this is inside the pool
Fri, Jul 22, 5:03 AM · Restricted Project, Restricted Project
huixie90 committed rGc559964d85e8: [libc++][ranges] implement `std::ranges::includes` (authored by huixie90).
[libc++][ranges] implement `std::ranges::includes`
Fri, Jul 22, 2:31 AM · Restricted Project, Restricted Project
huixie90 closed D130116: [libc++][ranges] implement `std::ranges::includes`.
Fri, Jul 22, 2:31 AM · Restricted Project, Restricted Project
huixie90 committed rG0f6364b8a100: [libc++][ranges] implement `std::ranges::equal_range` (authored by huixie90).
[libc++][ranges] implement `std::ranges::equal_range`
Fri, Jul 22, 2:28 AM · Restricted Project, Restricted Project
huixie90 closed D129796: [libc++][ranges] implement `std::ranges::equal_range`.
Fri, Jul 22, 2:27 AM · Restricted Project, Restricted Project

Thu, Jul 21

huixie90 updated the diff for D130116: [libc++][ranges] implement `std::ranges::includes`.

rebase

Thu, Jul 21, 3:32 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

rebase

Thu, Jul 21, 3:29 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D128864: [libc++] Fix algorithms which use reverse_iterator.
Thu, Jul 21, 3:25 PM · Restricted Project, Restricted Project

Wed, Jul 20

huixie90 added a reviewer for D130212: [libc++][ranges] attempt to fix proxy iterator issues that cause Chromium to crash: eaeltsin.
Wed, Jul 20, 4:21 PM · Restricted Project, Restricted Project
huixie90 requested review of D130212: [libc++][ranges] attempt to fix proxy iterator issues that cause Chromium to crash.
Wed, Jul 20, 4:12 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D130116: [libc++][ranges] implement `std::ranges::includes`.

address review issues

Wed, Jul 20, 3:05 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

fix merge conflicts

Wed, Jul 20, 2:48 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

add static_assert

Wed, Jul 20, 2:38 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130197: [libc++] Fix `_IterOps::__iter_move` to support proxy iterators..
Wed, Jul 20, 2:04 PM · Restricted Project, Restricted Project
huixie90 accepted D130070: [libc++][ranges] Implement `std::ranges::partition_{point,copy}`..

LGTM with nits

Wed, Jul 20, 1:50 AM · Restricted Project, Restricted Project

Tue, Jul 19

huixie90 updated the diff for D130124: [libc++][ranges] fix `std::search_n` incorrect `static_assert`.

address comments

Tue, Jul 19, 3:00 PM · Restricted Project, Restricted Project
huixie90 added a comment to D130124: [libc++][ranges] fix `std::search_n` incorrect `static_assert`.

Should we add a similar test in std::search and others that have a similar pattern?

Tue, Jul 19, 2:45 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130124: [libc++][ranges] fix `std::search_n` incorrect `static_assert`.
Tue, Jul 19, 2:30 PM · Restricted Project, Restricted Project
huixie90 requested review of D130124: [libc++][ranges] fix `std::search_n` incorrect `static_assert`.
Tue, Jul 19, 2:00 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D130070: [libc++][ranges] Implement `std::ranges::partition_{point,copy}`..
Tue, Jul 19, 1:18 PM · Restricted Project, Restricted Project
huixie90 requested review of D130116: [libc++][ranges] implement `std::ranges::includes`.
Tue, Jul 19, 1:02 PM · Restricted Project, Restricted Project
huixie90 accepted D129741: [libc++][ranges][NFC] Consolidate range algorithm checks for returning `dangling`..
Tue, Jul 19, 10:18 AM · Restricted Project, Restricted Project
huixie90 accepted D130057: [libc++][ranges][NFC] Test that range algorithms support iterators requiring `iter_move`..
Tue, Jul 19, 3:09 AM · Restricted Project, Restricted Project
huixie90 added inline comments to D124079: [libc++] Implement ranges::find_end, ranges::search{, _n}.
Tue, Jul 19, 1:33 AM · Restricted Project, Restricted Project

Mon, Jul 18

huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

rebase

Mon, Jul 18, 2:04 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D129794: [libc++] Fix reverse_iterator::iterator_concept.
Mon, Jul 18, 1:47 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

update one more caller

Mon, Jul 18, 2:31 AM · Restricted Project, Restricted Project
huixie90 accepted D129624: [libc++][ranges] Implement `ranges::{,stable_}partition`..

The algorithm LGTM. Regarding testing, I still prefer to have extra tests to verify iter_move and/or iter_swap is correctly used

Mon, Jul 18, 2:19 AM · Restricted Project, Restricted Project
huixie90 added inline comments to D129741: [libc++][ranges][NFC] Consolidate range algorithm checks for returning `dangling`..
Mon, Jul 18, 1:43 AM · Restricted Project, Restricted Project
huixie90 accepted D129968: [libc++] Add a bunch of missing _LIBCPP_HIDE_FROM_ABI.
Mon, Jul 18, 1:35 AM · Restricted Project, Restricted Project
huixie90 accepted D129976: [libc++] Add clang-tidy for the tests.

thanks for the update

Mon, Jul 18, 1:21 AM · Restricted Project, Restricted Project

Sun, Jul 17

huixie90 added inline comments to D129796: [libc++][ranges] implement `std::ranges::equal_range`.
Sun, Jul 17, 1:56 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

address feedback

Sun, Jul 17, 1:56 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D129823: [libc++][ranges] Make range algorithms support proxy iterators.
Sun, Jul 17, 1:59 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

try again

Sun, Jul 17, 1:36 AM · Restricted Project, Restricted Project

Sat, Jul 16

huixie90 accepted D129823: [libc++][ranges] Make range algorithms support proxy iterators.

LGTM with green ci
we could follow up with more testing for iter_move

Sat, Jul 16, 2:42 PM · Restricted Project, Restricted Project

Fri, Jul 15

huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

try again to fix CI

Fri, Jul 15, 12:01 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D129859: [libc++][ranges] Implement `ranges::{prev, next}_permutation`.
Fri, Jul 15, 10:36 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

try again to fix CI

Fri, Jul 15, 8:47 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D129796: [libc++][ranges] implement `std::ranges::equal_range`.

fix CI

Fri, Jul 15, 7:45 AM · Restricted Project, Restricted Project
huixie90 published D129796: [libc++][ranges] implement `std::ranges::equal_range` for review.
Fri, Jul 15, 6:56 AM · Restricted Project, Restricted Project
huixie90 accepted D129806: [libc++][ranges] Implement `ranges::replace_copy{,_if}`..
Fri, Jul 15, 6:35 AM · Restricted Project, Restricted Project
huixie90 requested changes to D129823: [libc++][ranges] Make range algorithms support proxy iterators.
Fri, Jul 15, 2:59 AM · Restricted Project, Restricted Project

Thu, Jul 14

huixie90 committed rG3151b95dad40: [libc++][ranges] implement `std::ranges::set_union` (authored by huixie90).
[libc++][ranges] implement `std::ranges::set_union`
Thu, Jul 14, 1:06 PM · Restricted Project, Restricted Project
huixie90 closed D129657: [libc++][ranges] implement `std::ranges::set_union`.
Thu, Jul 14, 1:06 PM · Restricted Project, Restricted Project
huixie90 accepted D129794: [libc++] Fix reverse_iterator::iterator_concept.

LGTM with nits

Thu, Jul 14, 1:01 PM · Restricted Project, Restricted Project
huixie90 added inline comments to D128864: [libc++] Fix algorithms which use reverse_iterator.
Thu, Jul 14, 8:12 AM · Restricted Project, Restricted Project
huixie90 added inline comments to D129741: [libc++][ranges][NFC] Consolidate range algorithm checks for returning `dangling`..
Thu, Jul 14, 2:30 AM · Restricted Project, Restricted Project

Wed, Jul 13

huixie90 added inline comments to D128864: [libc++] Fix algorithms which use reverse_iterator.
Wed, Jul 13, 11:31 PM · Restricted Project, Restricted Project
huixie90 updated the diff for D129657: [libc++][ranges] implement `std::ranges::set_union`.

address review feedback

Wed, Jul 13, 1:36 PM · Restricted Project, Restricted Project
huixie90 committed rGa5c0638dec83: [libc++][ranges] implement `std::ranges::set_symmetric_difference` (authored by huixie90).
[libc++][ranges] implement `std::ranges::set_symmetric_difference`
Wed, Jul 13, 1:25 PM · Restricted Project, Restricted Project
huixie90 closed D129520: [libc++][ranges] implement `std::ranges::set_symmetric_difference`.
Wed, Jul 13, 1:25 PM · Restricted Project, Restricted Project
huixie90 published D129657: [libc++][ranges] implement `std::ranges::set_union` for review.
Wed, Jul 13, 9:24 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D129520: [libc++][ranges] implement `std::ranges::set_symmetric_difference`.

rename variables

Wed, Jul 13, 4:07 AM · Restricted Project, Restricted Project
huixie90 accepted D128744: [libc++][ranges] Implement `ranges::partial_sort`..
Wed, Jul 13, 1:36 AM · Restricted Project, Restricted Project
huixie90 added inline comments to D129520: [libc++][ranges] implement `std::ranges::set_symmetric_difference`.
Wed, Jul 13, 12:31 AM · Restricted Project, Restricted Project
huixie90 updated the diff for D129520: [libc++][ranges] implement `std::ranges::set_symmetric_difference`.

addressed review feedback

Wed, Jul 13, 12:30 AM · Restricted Project, Restricted Project
huixie90 added a comment to D129414: [libc++][ranges][NFC] Consolidate some repetitive range algorithm tests:.

It seems that the "ranges_robust_against_copying_xxx" tests are in "test/libcxx/algorithms" and these "ranges_robust_against_" tests are in "test/std/algorithms".
Is there a reason for using different directories?

Wed, Jul 13, 12:14 AM · Restricted Project, Restricted Project