Bug 88580 - Parameter pack expansion fails (variadic constructor template inside a variadic class template)
Summary: Parameter pack expansion fails (variadic constructor template inside a variad...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: 12.0
Assignee: Patrick Palka
URL:
Keywords: rejects-valid
: 59716 84464 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-12-23 00:04 UTC by Petr Filipsky
Modified: 2022-04-30 16:01 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-04-26 00:00:00


Attachments
test.ii (230 bytes, text/plain)
2020-01-09 18:13 UTC, Zavadovsky Yan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Filipsky 2018-12-23 00:04:25 UTC
The following simple code snippet compiles as expected on clang, msvc and icc, but fails to compile on gcc (any version I have tried):

[https://godbolt.org/z/2uLKgn]

#include <string>

struct Policy {
    explicit Policy(std::string arg) {}
};

template <typename... Base>
struct Scope : private Base... {
  template <typename... T>
  Scope(T&&... args)
      : Base(std::forward<T>(args)...)... {
  }
};

int main() {
    const auto scope = Scope<Policy>{std::string{}};
}

... with following (seemingly meaningless) error:

   error: no matching function for call to 'Policy::Policy(bool)'

If any of the parameter packs is replaced with a single template parameter then the code compiles OK. So it seems that compiler is confused by combination of two pack expansions.

Sorry if this kind of error has been reported already (I know that there are already several bugs reported regarding variadic template parameter expansion but none of them seemed to me identical to this one).
Comment 1 Zavadovsky Yan 2020-01-09 18:12:00 UTC
Got same bug with all GCC version since (at least, doesn't check older versions) 6.3.0 and newer.

Code:
<code>
struct Base
{
	Base(void*) { }
	virtual ~Base() { }
};

template< typename... Ts > struct Derived : public Ts...
{
	template< typename... Us > Derived(Us... args) : Ts(args...)... { }
};

int main()
{
	Derived<Base> d((void*)0);
	return 0;
}
</code>

Clang++ compiles it.

GCC reports error:
<code>
test.cpp: In instantiation of ‘Derived<Ts>::Derived(Us ...) [with Us = {void*}; Ts = {Base}]’:
test.cpp:14:26:   required from here
test.cpp:9:62: error: no matching function for call to ‘Base::Base(bool)’
    9 |  template< typename... Us > Derived(Us... args) : Ts(args...)... { }
      |                                                              ^~~
test.cpp:3:2: note: candidate: ‘Base::Base(void*)’
    3 |  Base(void*) { }
      |  ^~~~
test.cpp:3:7: note:   no known conversion for argument 1 from ‘bool’ to ‘void*’
    3 |  Base(void*) { }
      |       ^~~~~
test.cpp:1:8: note: candidate: ‘constexpr Base::Base(const Base&)’
    1 | struct Base
      |        ^~~~
test.cpp:1:8: note:   no known conversion for argument 1 from ‘bool’ to ‘const Base&’
</code>

Compilation command: g++ -std=c++14 -c test.cpp

GCC version:
<code>
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
</code>
Comment 2 Zavadovsky Yan 2020-01-09 18:13:01 UTC
Created attachment 47622 [details]
test.ii

gcc --save-temps output
Comment 3 Zavadovsky Yan 2020-01-09 18:17:42 UTC
(In reply to Petr Filipsky from comment #0)
> Sorry if this kind of error has been reported already (I know that there are
> already several bugs reported regarding variadic template parameter
> expansion but none of them seemed to me identical to this one).

I also can't find similar bugs except this one created by you.
Comment 4 Ruslan Altynbaev 2021-04-24 11:16:30 UTC
Works if I change

    : Base(std::forward<T>(args)...)...

To

    : Base{std::forward<T>(args)...}...
Comment 5 GCC Commits 2021-04-27 18:22:32 UTC
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:37d2b98100cefcb9d312d379473c12aa6d61fc62

commit r12-174-g37d2b98100cefcb9d312d379473c12aa6d61fc62
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Apr 27 14:18:25 2021 -0400

    c++: Fix Bases(args...)... base initialization [PR88580]
    
    When substituting into the arguments of a base initializer pack
    expansion, tsubst_initializer_list uses a dummy EXPR_PACK_EXPANSION
    in order to expand an initializer such as Bases(args)... into
    Bases#{0}(args#{0}) and so on.  But when an argument inside the base
    initializer is itself a pack expansion, as in Bases(args...)..., the
    argument is already an EXPR_PACK_EXPANSION so we don't need to wrap it.
    It's also independent from the outer expansion of Bases, so we need to
    "multiplicatively" append the expansion of args... onto the argument
    list of each expanded base.
    
    gcc/cp/ChangeLog:
    
            PR c++/88580
            * pt.c (tsubst_initializer_list): Correctly handle the case
            where an argument inside a base initializer pack expansion is
            itself a pack expansion.
    
    gcc/testsuite/ChangeLog:
    
            PR c++/88580
            * g++.dg/cpp0x/variadic182.C: New test.
Comment 6 Patrick Palka 2021-04-27 18:25:10 UTC
Thanks for the bug report.  This should now be fixed for GCC 12.
Comment 7 Andrew Pinski 2021-12-08 18:58:57 UTC
*** Bug 84464 has been marked as a duplicate of this bug. ***
Comment 8 Patrick Palka 2022-04-30 16:01:19 UTC
*** Bug 59716 has been marked as a duplicate of this bug. ***