[Bug c++/99103] New: Initializer-list constructors in CTAD for vector is still wrong

[Bug c++/99103] New: Initializer-list constructors in CTAD for vector is still wrong

[oleksandr.koval.dev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103

            Bug ID: 99103
           Summary: Initializer-list constructors in CTAD for vector is
                    still wrong
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: oleksandr.koval.dev at gmail dot com
  Target Milestone: ---

According to P0702R1, initializer-list constructors for T should be ignored
during CTAD if list contains a single element of cv U when U is a
specialization or a child of T. It works for simple things like:

std::vector v{std::vector{1, 2, 3}};
static_assert(std::is_same_v<decltype(v), std::vector<int>>); // fine

But not for this one:

template<typename... Args>
auto make_vector(const Args&... elems){
    return std::vector{elems...};
}
auto v2 = make_vector(std::vector{1,2,3});
static_assert(std::is_same_v<decltype(v2), std::vector<int>>); // fails
static_assert(std::is_same_v<decltype(v2), std::vector<std::vector<int>>>); //
OK

[Bug c++/99103] Initializer-list constructors in CTAD for vector is still wrong

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-02-15
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Thanks for the bug report, confirmed.  We can trigger the bug without the
variadic template:

const std::vector<int> v;
std::vector w{v};
static_assert(std::is_same_v<decltype(w), std::vector<int>>); // fails

Investigating.

[Bug c++/99103] Initializer-list constructors in CTAD for vector is still wrong

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:676f6f3277181662cf3ed07769edfa2d4fb7df28

commit r11-7405-g676f6f3277181662cf3ed07769edfa2d4fb7df28
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Feb 25 16:38:08 2021 -0500

    c++: Fix CTAD of single-element initializer list [PR99103]

    When determining whether to rule out initializer-list constructors
    during CTAD with a single-element initializer list (as per P0702), the
    element type's cv-qualifiers should be irrelevant.  This patch fixes
    this by making is_spec_or_derived strip cv-qualifiers from the supplied
    expression type.

    In passing, I noticed in maybe_aggr_guide we were calling
    is_spec_or_derived with swapped arguments.  This led us to prefer the
    aggregate deduction candidate over copying deduction in the second
    testcase below with -std=c++20.

    gcc/cp/ChangeLog:

            PR c++/99103
            * pt.c (is_spec_or_derived): Drop cv-qualifiers from 'etype'.
            (maybe_aggr_guide): Fix order of arguments to is_spec_or_derived.

    gcc/testsuite/ChangeLog:

            PR c++/99103
            * g++.dg/cpp1z/class-deduction79.C: New test.
            * g++.dg/cpp1z/class-deduction80.C: New test.

[Bug c++/99103] Initializer-list constructors in CTAD for vector is still wrong

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11.