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

Only first destructor is considered when constraints are used #45614

Closed
qookei opened this issue Jun 10, 2020 · 5 comments
Closed

Only first destructor is considered when constraints are used #45614

qookei opened this issue Jun 10, 2020 · 5 comments
Labels
bugzilla Issues migrated from bugzilla c++20 clang:frontend Language frontend issues, e.g. anything involving "Sema" concepts C++20 concepts

Comments

@qookei
Copy link
Member

qookei commented Jun 10, 2020

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.

@efriedma-quic
Copy link
Collaborator

efriedma-quic commented Jun 10, 2020

[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>);

@zygoloid
Copy link
Mannequin

zygoloid mannequin commented Jun 11, 2020

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@jwakely
Copy link
Contributor

jwakely commented Jan 4, 2022

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

@miscco
Copy link
Contributor

miscco commented Apr 4, 2022

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

@EugeneZelenko EugeneZelenko added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Apr 4, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Apr 4, 2022

@llvm/issue-subscribers-clang-frontend

finomen pushed a commit to daedaleanai/llvm-project that referenced this issue Nov 3, 2022
This patch implements a necessary part of P0848, the overload resolution for destructors.
It is now possible to overload destructors based on constraints, and the eligible destructor
will be selected at the end of the class.

The approach this patch takes is to perform the overload resolution in Sema::ActOnFields
and to mark the selected destructor using a new property in FunctionDeclBitfields.

CXXRecordDecl::getDestructor is then modified to use this property to return the correct
destructor.

This closes llvm#45614.

Reviewed By: #clang-language-wg, erichkeane

Differential Revision: https://reviews.llvm.org/D126194
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++20 clang:frontend Language frontend issues, e.g. anything involving "Sema" concepts C++20 concepts
Projects
Status: No status
Development

No branches or pull requests

7 participants