Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__is_trivially_equality_comparable(T) false positive when the defaulted operator is ineligible #89293

Closed
AMP999 opened this issue Apr 18, 2024 · 1 comment · Fixed by #93113
Closed
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@AMP999
Copy link
Contributor

AMP999 commented Apr 18, 2024

Clang's __is_trivially_equality_comparable(T) builtin assumes that if a type has any defaulted trivial comparison operator, then all its comparison operators will be tantamount-to-trivial. That's a sane assumption... but only if the defaulted operator is actually eligible for the given T! If the defaulted operator is requires-clause'd away, then we shouldn't consider it relevant to the question of triviality at all.
https://godbolt.org/z/3hs4EKPKT

template<bool B>
struct S {
    int i;
    bool operator==(const S&) const requires B = default;
    bool operator==(const S& rhs) const { return (i % 3) == (rhs.i % 3); }
};
static_assert(__is_trivially_equality_comparable(S<true>)); // OK
static_assert(not __is_trivially_equality_comparable(S<false>)); // Oops, this line assert-fails

This compiler misbehavior causes libc++ to miscompile std::equal:
https://godbolt.org/z/YPfEG6cv9

    S<false> a[] = {1,2,3};
    S<false> b[] = {4,5,6};
    return std::equal(a, a+3, b, b+3);
      // should be true, not false
@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed new issue labels Apr 18, 2024
@llvmbot
Copy link
Member

llvmbot commented Apr 18, 2024

@llvm/issue-subscribers-clang-frontend

Author: Amirreza Ashouri (AMP999)

Clang's `__is_trivially_equality_comparable(T)` builtin assumes that if a type has _any_ defaulted trivial comparison operator, then _all_ its comparison operators will be tantamount-to-trivial. That's a sane assumption... but only if the defaulted operator is actually eligible for the given `T`! If the defaulted operator is `requires`-clause'd away, then we shouldn't consider it relevant to the question of triviality at all. https://godbolt.org/z/3hs4EKPKT ``` template<bool B> struct S { int i; bool operator==(const S&) const requires B = default; bool operator==(const S& rhs) const { return (i % 3) == (rhs.i % 3); } }; static_assert(__is_trivially_equality_comparable(S<true>)); // OK static_assert(not __is_trivially_equality_comparable(S<false>)); // Oops, this line assert-fails ``` This compiler misbehavior causes libc++ to miscompile `std::equal`: https://godbolt.org/z/YPfEG6cv9 ``` S<false> a[] = {1,2,3}; S<false> b[] = {4,5,6}; return std::equal(a, a+3, b, b+3); // should be true, not false ```

philnik777 added a commit that referenced this issue Jun 27, 2024
…eligebile defaulted overloads (#93113)

This changes `__is_trivially_equality_comparable` to do overload
resolution instead, which fixes a couple of false-positives (and a
false-negative as a drive-by).

Fixes #89293
lravenclaw pushed a commit to lravenclaw/llvm-project that referenced this issue Jul 3, 2024
…eligebile defaulted overloads (llvm#93113)

This changes `__is_trivially_equality_comparable` to do overload
resolution instead, which fixes a couple of false-positives (and a
false-negative as a drive-by).

Fixes llvm#89293
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
3 participants