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

[concepts] CTAD does not propagate constructor constraints to deduction guides #57646

Closed
williamspatrick opened this issue Sep 9, 2022 · 5 comments
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" concepts C++20 concepts

Comments

@williamspatrick
Copy link

williamspatrick commented Sep 9, 2022

Sample:

#include <iostream>
#include <string>

template <bool A = false, bool B = false>
struct foo
{
    constexpr foo() requires (!A && !B) = default;
    constexpr foo() requires (A || B) = delete;

    std::string value = "Hello World!";
};

int main()
{
    foo<> works{};
    std::cout << works.value << std::endl;

    foo fails{};

    return 0;
}

https://godbolt.org/z/coxs3PvbE

This fails with:

<source>:18:9: error: ambiguous deduction for template arguments of 'foo'
    foo fails{};
        ^
<source>:7:15: note: candidate function [with A = false, B = false]
    constexpr foo() requires (!A && !B) = default;
              ^
<source>:8:15: note: candidate function [with A = false, B = false]
    constexpr foo() requires (A || B) = delete;

The same code passes with GCC 12.

@tbaederr tbaederr added clang:frontend Language frontend issues, e.g. anything involving "Sema" concepts C++20 concepts and removed new issue labels Sep 9, 2022
@llvmbot
Copy link
Member

llvmbot commented Sep 9, 2022

@llvm/issue-subscribers-clang-frontend

@royjacobson
Copy link
Contributor

royjacobson commented Sep 9, 2022

I tried to understand what the standard says here, and AFAICT the overload resolution in the CTAD here happens in terms of implicitly generated deduction guides which don't propagate the trailing requires from the constructors (see [over.match.class.deduct]). So I think this is technically ambiguous.

Relevant GCC discussion from last year: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg257689.html

Wish they'd file a CWG issue for this.

@royjacobson royjacobson changed the title [concepts] unexpected "ambiguous deduction for template arguments" [concepts] CTAD does not propagate constructor constraints Sep 9, 2022
@royjacobson royjacobson changed the title [concepts] CTAD does not propagate constructor constraints [concepts] CTAD does not propagate constructor constraints to deduction guides Sep 9, 2022
@royjacobson
Copy link
Contributor

Great, this is also a duplicate of almost 3-years old #43829.

@royjacobson
Copy link
Contributor

This is now CWG2528. I don't see a reason not to implement the suggested fix, since GCC/MSVC already do it.

@royjacobson
Copy link
Contributor

veselypeta pushed a commit to veselypeta/cherillvm that referenced this issue May 10, 2024
Implement suggested fix for [[ https://cplusplus.github.io/CWG/issues/2628.html | DR2628. ]] Couldn't update the DR docs because there hasn't been a DR index since it was filed, but the tests still run in CI.

Note: I only transfer the constructor constraints, not the struct constraints. I think that's OK because the struct constraints are the same
for all constructors so they don't affect the overload resolution, and if they deduce to something that doesn't pass the constraints
we catch it anyway. So (hopefully) that should be more efficient without sacrificing correctness.

Closes:
llvm/llvm-project#57646
llvm/llvm-project#43829

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D134145
a2flo pushed a commit to a2flo/floor_llvm that referenced this issue Feb 2, 2025
[Clang] Implement fix for DR2628

Implement suggested fix for [[ https://cplusplus.github.io/CWG/issues/2628.html | DR2628. ]] Couldn't update the DR docs because there hasn't been a DR index since it was filed, but the tests still run in CI.

Note: I only transfer the constructor constraints, not the struct constraints. I think that's OK because the struct constraints are the same
for all constructors so they don't affect the overload resolution, and if they deduce to something that doesn't pass the constraints
we catch it anyway. So (hopefully) that should be more efficient without sacrificing correctness.

Closes:
llvm#57646
llvm#43829

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D134145
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" concepts C++20 concepts
Projects
Status: No status
Development

No branches or pull requests

4 participants