clang rejects default constexpr operator of a templated type when instantiated with non-constexpr comparable object

[hanickadot]

I was writing a generic code and found an issue with defaulted comparison operator if they are constexpr in a template, and then I instantiate it with non-constexpr comparable type. I think it should be accepted, especially if I write this code manually the constexpr-ness will be downgraded silently.

https://compiler-explorer.com/z/4fbasY6Pb

[shafik]

Code:

template <typename A> struct my_struct {
    A value;

    constexpr friend bool operator==(const my_struct &, const my_struct &) noexcept = default;
};

struct non_constexpr_type {
    friend bool operator==(non_constexpr_type, non_constexpr_type) noexcept {
        return false;
    }
};

my_struct<non_constexpr_type> obj;

Note that gcc/MSVC accept this: https://compiler-explorer.com/z/89eGnfnnT

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[shafik]

So I am looking at bc24014 which I believe is what implemented this, based on https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2002r0.html and if I am reading it right I believe your code should be well-formed since the first defaulted declaration is constexpr.

If this is the case then I think modifying DefaultedComparisonAnalyzer::visitBinaryOperator and changing R.Constexpr &= BestFD->isConstexpr(); to R.Constexpr &= BestFD->isConstexpr() || FD->isConstexpr(); might work but perhaps there is a more detailed set of changes involved. I have not run check-clang to verify that does not break other stuff as well.

CC @zygoloid to see if I am on the right track.

[zygoloid]

Historically, and under P2002R0, constructs like this were ill-formed. Writing constexpr on a defaulted declaration was a way to say "I need this to be constexpr, please give me an error if it can't be", and if the behavior you wanted was "make this constexpr if it can be", then you'd get that behavior by writing nothing at all. Eg:

-    constexpr friend bool operator==(const my_struct &, const my_struct &) noexcept = default;
+    friend bool operator==(const my_struct &, const my_struct &) noexcept = default;

This was changed by P2448R2, which struck a bunch of rules, including that one. constexpr now only means "allow use of this in constant expressions" and never means "give me an error if you can't do so".

P2448 was agreed by EWG to not be a DR, so it does not apply retroactively, meaning that a diagnostic is required for this program in C++20 and earlier. It would seem reasonable, however, for Clang to allow such code as an extension (with an ExtWarn or Extension diagnostic instead of an Error -- and I'd suggest an Extension given that the other compilers silently accept) in C++20.

[shafik]

Interesting InGroup<CXX2b> does not work w/ Extension but does work with ExtWarn. It looks like Extension defaults to warning that it is a C++20 extension. It looks like the other cases C++11, C++14 and C++17 extension warning all use ExtWarn.

[shafik]

PR: https://reviews.llvm.org/D146090

@zygoloid I think my PR reflects that intent in your comments but please feel free to let me know if I got it wrong in any way.

[llvmbot]

@llvm/issue-subscribers-c-2b