[all-commits] [llvm/llvm-project] 8938bc: [libc++][hardening] Categorize assertions related ...

[Konstantin Varlamov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8938bc0ad0651f8d481cca2b2b98345d34b3aabe
      https://github.com/llvm/llvm-project/commit/8938bc0ad0651f8d481cca2b2b98345d34b3aabe
  Author: Konstantin Varlamov <varconsteq at gmail.com>
  Date:   2024-01-22 (Mon, 22 Jan 2024)

  Changed paths:
    M libcxx/include/__algorithm/comp_ref_type.h
    M libcxx/include/__algorithm/nth_element.h
    M libcxx/include/__algorithm/sort.h
    M libcxx/include/__algorithm/three_way_comp_ref_type.h
    M libcxx/include/__config
    M libcxx/include/__debug_utils/strict_weak_ordering_check.h
    R libcxx/test/libcxx/algorithms/alg.sorting/assert.sort.invalid_comparator.pass.cpp
    A libcxx/test/libcxx/algorithms/alg.sorting/assert.sort.invalid_comparator/assert.sort.invalid_comparator.oob.pass.cpp
    A libcxx/test/libcxx/algorithms/alg.sorting/assert.sort.invalid_comparator/assert.sort.invalid_comparator.pass.cpp
    A libcxx/test/libcxx/algorithms/alg.sorting/assert.sort.invalid_comparator/bad_comparator_values.h
    A libcxx/test/libcxx/algorithms/alg.sorting/assert.sort.invalid_comparator/invalid_comparator_utilities.h
    R libcxx/test/libcxx/algorithms/alg.sorting/bad_comparator_values.h

  Log Message:
  -----------
  [libc++][hardening] Categorize assertions related to strict weak ordering (#77405)

If a user passes a comparator that doesn't satisfy strict weak ordering
(see https://eel.is/c++draft/algorithms#alg.sorting.general) to
a sorting algorithm, the algorithm can produce an incorrect result or
even lead
to an out-of-bounds access. Unfortunately, comprehensively validating
that a given comparator indeed satisfies the strict weak ordering
requirement is prohibitively expensive (see [the related
RFC](https://discourse.llvm.org/t/rfc-strict-weak-ordering-checks-in-the-debug-libc/70217)).
As a result, we have three independent sets of checks:

- assertions that catch out-of-bounds accesses within the algorithms'
  implementation. These are relatively cheap; however, they cannot catch
  the underlying cause and cannot prevent the case where an invalid
  comparator would result in an incorrectly-sorted sequence without
  actually triggering an OOB access;

- debug comparators that wrap a given comparator and on each comparison
  check that if `(a < b)`, then `!(b < a)`, where `<` stands for the
  user-provided comparator. This performs up to 2x number of comparisons
  but doesn't affect the algorithmic complexity. While this approach can
  find more issues, it is still a heuristic;

- a comprehensive check of the comparator that validates up to 100
  elements in the resulting sorted sequence (see the RFC above for
details). The check is expensive but the 100 element limit can somewhat
  compensate for that, especially for large values of `N`.

The first set of checks is enabled in the fast hardening mode while the
other two are only enabled in the debug mode.

This patch also removes the
`_LIBCPP_DEBUG_STRICT_WEAK_ORDERING_CHECK` macro that
previously was used to selectively enable the 100-element check.
Now this check is enabled unconditionally in the debug mode.

Also, introduce a new category
`_LIBCPP_ASSERT_SEMANTIC_REQUIREMENT`. This category is
intended for checking the semantic requirements from the Standard.
Typically, these are hard or impossible to completely validate, so
these checks are expected to be heuristic in nature and potentially
quite expensive.

See https://reviews.llvm.org/D150264 for additional background.
Fixes #71496