[libcxx-commits] [libcxx] [libc++] Make sure `flat_{multi}map::key_compare` handle `boolean-testable` correctly (PR #132621)

[A. Jiang via libcxx-commits]

================
@@ -846,7 +846,7 @@ class flat_map {
         __compare_(std::forward<_CompArg>(__comp)...) {}
 
   _LIBCPP_HIDE_FROM_ABI bool __is_sorted_and_unique(auto&& __key_container) const {
-    auto __greater_or_equal_to = [this](const auto& __x, const auto& __y) { return !__compare_(__x, __y); };
+    auto __greater_or_equal_to = [this](const auto& __x, const auto& __y) -> bool { return !__compare_(__x, __y); };
----------------
frederick-vs-ja wrote:

> > I recalled that the current standard wording doesn't actually require the result type of `Predicate` of `erase_if` for `flat_meow` to model _`boolean-testable`_. The boolean-testablity requirements seem only imposed for `erase_if` for sequence containers.
> 
> I mainly referred to https://eel.is/c++draft/algorithms#requirements-6

I meant that such requirement doesn't seem properly propagated to `erase_if` for non-sequence containers and container adaptors. (And possibly `hive`?)
- For `basic_string`, `deque`, `inplace_vector`, and `vector`, the requirements are propagated via equivalent-to code that uses `std::remove_if`.
- For `forward_list` and `list`, the requirements are propagated via [[forward.list.ops]](https://eel.is/c++draft/forward.list.ops), [[list.ops]](https://eel.is/c++draft/list.ops) and equivalent-to code that uses member `remove_if`.

But for other containers and container adaptors, there doesn't seem such requirement propagation. For `hive` it's quite weird that [[hive.operations]](https://eel.is/c++draft/hive.operations) propagates the requirements, but `erase_if` isn't in that subclause.

https://github.com/llvm/llvm-project/pull/132621