llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

Home Page:http://llvm.org

Repository from Github https://github.comllvm/llvm-projectRepository from Github https://github.comllvm/llvm-project

Only first destructor is considered when constraints are used

qookei opened this issue · comments

Bugzilla Link 46269
Version trunk
OS Linux
CC @efriedma-quic,@qookei,@zygoloid,@saarraz

Extended Description

When there are multiple destructors constrained with a requires clause, only the first one is considered, like in the following code:

template <bool B>
struct A {
    ~A() requires (B) { }
    ~A() requires (!B) { }
};

A<false> x;

The compiler reports the following error:

<source>:7:10: error: invalid reference to function '~A': constraints not satisfied
A<false> x;
         ^
<source>:3:20: note: because 'false' evaluated to false
    ~A() requires (B) { }
                   ^

The compiler prematurely reports an error about an invalid reference to the destructor because the constraint on the first variant was not satisfied, without checking the second variant.

The same code compiles with GCC without any problems.

[class.dtor]p4: "At the end of the definition of a class, overload resolution is performed among the prospective destructors declared in that class with an empty argument list to select the destructor for the class, also known as the selected destructor. The program is ill-formed if overload resolution fails." So I guess that should be accepted.

On a related note, both clang and gcc accept the following, which seems wrong:

template <bool B> struct A {
    ~A() requires (B) { }
};
int x = sizeof(A<false>);

I don't believe we implement any of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0848r3.html (which added the eligible special member & prospective destructor rules) yet.

N.B. P2493R0 proposes an update to __cpp_concepts to indicate support for this feature.

Is there anyone working on this. It also affects other features such as expected which creates conformance issues

@llvm/issue-subscribers-clang-frontend