[Bug c++/96251] New: co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[Bug c++/96251] New: co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[yuri.kilochek at gmail dot com]

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

            Bug ID: 96251
           Summary: co_yield incorrectly rejected in
                    non-explicitly-constexpr generic lambda
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yuri.kilochek at gmail dot com
  Target Milestone: ---

Created attachment 48898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48898&action=edit
preprocessed test source

Given `test.cpp`:

    #include <coroutine>

    struct coroutine {
        struct promise_type {
            auto get_return_object() { return coroutine(); }
            auto initial_suspend() { return std::suspend_always(); }
            auto yield_value(int) { return std::suspend_always(); }
            void return_void() {}
            auto final_suspend() { return std::suspend_always(); }
            void unhandled_exception() {}
        };
    };

    int main() {
        auto f = [](auto max) -> coroutine {
            for (int i = 0; i < max; ++i) {
                co_yield i;
            }
        };

        f(10);
    }

Compiled with:

    g++ -v -save-temps -std=c++20 -fcoroutines test.cpp

The following diagnostic is produced:

    Using built-in specs.
    COLLECT_GCC=g++
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
    Target: x86_64-pc-linux-gnu
    Configured with: /build/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
    Thread model: posix
    Supported LTO compression algorithms: zlib zstd
    gcc version 10.1.0 (GCC) 
    COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
     /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++2a -fcoroutines -fpch-preprocess
-o test.ii
    ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
     /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../include/c++/10.1.0
    
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../include/c++/10.1.0/x86_64-pc-linux-gnu
    
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../include/c++/10.1.0/backward
     /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include
     /usr/local/include
     /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include-fixed
     /usr/include
    End of search list.
    COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
     /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++2a
-version -fcoroutines -o test.s
    GNU C++17 (GCC) version 10.1.0 (x86_64-pc-linux-gnu)
        compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

    GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
    GNU C++17 (GCC) version 10.1.0 (x86_64-pc-linux-gnu)
        compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

    GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
    Compiler executable checksum: 262bfe0a9d27898ea74cb944d94238f6
    test.cpp: In instantiation of ‘main()::<lambda(auto:1)> [with auto:1 =
int]’:
    test.cpp:21:10:   required from here
    test.cpp:17:13: error: ‘co_yield’ cannot be used in a ‘constexpr’ function
       17 |             co_yield i;
          |             ^~~~~~~~

Since coroutines cannot be `constexpr` (per [dcl.constexpr]/3.3), presence of
`co_yield` should simply disqualify the lambda from being implicitly constexpr
(as it would otherwise be due to [expr.prim.lambda.closure]/4).

Interestingly, if we make the lambda non-generic (e.g. replace `auto max` with
`int max`) it compiles and works fine.

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[yuri.kilochek at gmail dot com]

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

--- Comment #1 from Yuri Kilochek <yuri.kilochek at gmail dot com> ---
Created attachment 48899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48899&action=edit
source

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[yuri.kilochek at gmail dot com]

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

--- Comment #2 from Yuri Kilochek <yuri.kilochek at gmail dot com> ---
Created attachment 48900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48900&action=edit
stderr.txt

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-21
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
thanks for the report

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
So, as noted, the problem is being caused because the coroutine is being
regarded as potentially constexpr while still type-dependent, and then failing
during template expansion.

All the coroutine expressions are correctly marked as not suitable for
constexpr.

One can also use the DECL_COROUTINE_P on the function decl (which is added as
soon as any coroutine keyword is encountered - that would perhaps short-circuit
some work), but it doesn't fix the bug. ... like so.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 377fe322ee8..c4226599072 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7827,6 +7827,9 @@ potential_constant_expression_1 (tree t, bool want_rval,
bool strict, bool now,
   switch (TREE_CODE (t))
     {
     case FUNCTION_DECL:
+      if (DECL_COROUTINE_P (t))
+       return false;
+       /* FALLTHROUGH.  */
     case BASELINK:
     case TEMPLATE_DECL:
     case OVERLOAD:

===

The for loop body is never visited during the initial parse, but rather the
dependent type in the loop init expression causes a conservative early exit
(with a 'true' result).

It seems that this conservative approach to potentially-constexpr, means that
some way of punting in template expansion is needed (or the initial check needs
to be less conservative).

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail+gnu at tzik dot jp

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
*** Bug 98976 has been marked as a duplicate of this bug. ***

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 50206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50206&action=edit
Patch for testing

It seems most efficient to prevent the marking of the template as early as
possible (plus I was not able to figure out how to make the instantiation
process bail when it encountered a case that was not suitable for constexpr).

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
patch posted :
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565649.html

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:f13d9e48eeca7ed8f8df55c9a62fc9980d5606ad

commit r11-7357-gf13d9e48eeca7ed8f8df55c9a62fc9980d5606ad
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Tue Feb 23 12:54:26 2021 +0000

    coroutines : Adjust error handling for type-dependent coroutines [PR96251].

    Although coroutines are not permitted to be constexpr, generic lambdas
    are implicitly from C++17 and, because of this, a generic coroutine lambda
    can be marked as potentially constexpr. As per the PR, this then fails when
    type substitution is attempted because the check disallowing constexpr in
    the coroutines code was overly restrictive.

    This changes the error handing to mark the function  as 'invalid_constexpr'
    but suppresses the error in the case that we are instantiating a constexpr.

    gcc/cp/ChangeLog:

            PR c++/96251
            * coroutines.cc (coro_common_keyword_context_valid_p): Suppress
            error reporting when instantiating for a constexpr.

    gcc/testsuite/ChangeLog:

            PR c++/96251
            * g++.dg/coroutines/pr96251.C: New test.

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.3

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
so fixed on master.

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:0b0a579191828727c232d26b513e3f4d9eeb9b3d

commit r10-9504-g0b0a579191828727c232d26b513e3f4d9eeb9b3d
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Tue Feb 23 12:54:26 2021 +0000

    coroutines : Adjust error handling for type-dependent coroutines [PR96251].

    Although coroutines are not permitted to be constexpr, generic lambdas
    are implicitly from C++17 and, because of this, a generic coroutine lambda
    can be marked as potentially constexpr. As per the PR, this then fails when
    type substitution is attempted because the check disallowing constexpr in
    the coroutines code was overly restrictive.

    This changes the error handing to mark the function  as 'invalid_constexpr'
    but suppresses the error in the case that we are instantiating a constexpr.

    gcc/cp/ChangeLog:

            PR c++/96251
            * coroutines.cc (coro_common_keyword_context_valid_p): Suppress
            error reporting when instantiating for a constexpr.

    gcc/testsuite/ChangeLog:

            PR c++/96251
            * g++.dg/coroutines/pr96251.C: New test.

    (cherry picked from commit f13d9e48eeca7ed8f8df55c9a62fc9980d5606ad)

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed for 10.3 and GCC 11.1

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kacper.slominski72 at gmail dot co
                   |                            |m

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 96784 has been marked as a duplicate of this bug. ***