[Bug c++/114393] New: over eager "invalid use of void expression" ?

[Bug c++/114393] New: over eager "invalid use of void expression" ?

[prlw1 at cam dot ac.uk]

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

            Bug ID: 114393
           Summary: over eager "invalid use of void expression" ?
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prlw1 at cam dot ac.uk
  Target Milestone: ---

When trying to use the reference implementation of the `std::execution`
proposal over at https://github.com/nvidia/stdexec, I get errors of the form

/usr/src/local/stdexec/include/exec/async_scope.hpp:735:31: error: invalid use
of void expression
  735 |         return when_empty(just());

with `g++ (GCC) 14.0.1 20240318 (experimental)`

In https://github.com/NVIDIA/stdexec/issues/1285 Eric Niebler traces this to
a__make_sexpr invocations which can't ever have type void.

The easiest way to reproduce this is to see the standard example on goldbolt:
https://godbolt.org/z/3cseorf7M

It compiles fine with gcc 12.3 and 13.2 (even with `-Wall -Wextra
--pendantic-errors`, but not with gcc trunk, which possibly suggests a
regression.

I have been using stdexec successfully for a while with trunk. Old checkouts of
stdexec which used to work (with maybe gcc trunk from about 2 months ago?) now
fail, which also points towards a change in gcc rather than in stdexec.

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ?

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 57736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57736&action=edit
Gzipped preprocessed source

Bisecting ...

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ?

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-03-19
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
r14-2170 started to reject it

Author: Patrick Palka
Date:   Wed Jun 28 20:43:33 2023

    c++: ahead of time variable template-id coercion [PR89442]

    This patch makes us coerce the arguments of a variable template-id ahead
    of time, as we do for class template-ids, which causes us to immediately
    diagnose template parm/arg kind mismatches and arity mismatches.

    Unfortunately this causes a regression in cpp1z/constexpr-if20.C: coercing
    the variable template-id m<ar, as> ahead of time means we strip it of
    typedefs, yielding m<typename C<i>::q, typename C<j>::q>, but in this
    stripped form we're directly using 'i' and so we expect to have captured
    it.  This is a variable template version of PR107437.

            PR c++/89442
            PR c++/107437

    gcc/cp/ChangeLog:

            * cp-tree.h (lookup_template_variable): Add complain parameter.
            * parser.cc (cp_parser_template_id): Pass tf_warning_or_error
            to lookup_template_variable.
            * pt.cc (lookup_template_variable): Add complain parameter.
            Coerce template arguments here ...
            (finish_template_variable): ... instead of here.
            (lookup_and_finish_template_variable): Check for error_mark_node
            result from lookup_template_variable.
            (tsubst_copy) <case TEMPLATE_ID_EXPR>: Pass complain to
            lookup_template_variable.
            (instantiate_template): Use build2 instead of
            lookup_template_variable to build a TEMPLATE_ID_EXPR
            for most_specialized_partial_spec.

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Keywords|                            |rejects-valid

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reducing ...

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |c++-lambda

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This might come down to:
```
template <class _Descriptor, auto t = [] { return _Descriptor();}>
inline constexpr auto __descriptor_fn_v = t;
```

being handled wrong.

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase which shows this never worked:
```
template <auto _DescriptorFn> struct c1 {};

template <class _Descriptor, auto t = [] { return _Descriptor();}>
inline constexpr auto b_v = t;

template <class _Tag>
using c1_t = c1<b_v<int>>;

template <class _Data>
constexpr auto g(_Data __data) {
    return c1_t<_Data>{};
}

void f() {
  auto &&b = g(0);
}
```

I don't know understand how the original testcase worked in GCC 13 when the
above testcase never worked ...

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P2

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[ppalka at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917

commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917
Author: Patrick Palka <ppalka@redhat.com>

c++: templated substitution into lambda-expr [PR114393]

The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty which causes push_template_decl
to return error_mark_node from the call to begin_lambda_type.  Were it
not for the sanity check this silent error_mark_node result leads to
nonsensical errors down the line, or silent breakage.

In the first testcase, we hit this assert during instantiation of the
dependent alias template-id c1_t<_Data> from instantiate_template, which
clears current_template_parms via push_to_top_level.  Similar story for
the second testcase.  For the third testcase we hit the assert during
partial instantiation of the member template from instantiate_class_template
which similarly calls push_to_top_level.

These testcases illustrate that templated substitution into a lambda-expr
is not always possible, in particular when we lost the relevant template
context.  I experimented with recovering the template context by making
tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if
current_template_parms is empty which worked but seemed like a hack.  I
also experimented with preserving the template context by keeping
current_template_parms set during instantiate_template for a dependent
specialization which also worked but it's at odds with the fact that we
cache dependent specializations (and so they should be independent of
the template context).

So instead of trying to make such substitution work, this patch uses the
extra-args mechanism to defer templated substitution into a lambda-expr
when we lost the relevant template context.

        PR c++/114393
        PR c++/107457
        PR c++/93595

gcc/cp/ChangeLog:

        * cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define.
        (tree_lambda_expr::extra_args): New field.
        * module.cc (trees_out::core_vals) <case LAMBDA_EXPR>: Stream
        LAMBDA_EXPR_EXTRA_ARGS.
        (trees_in::core_vals) <case LAMBDA_EXPR>: Likewise.
        * pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR.
        (tree_extra_args): Handle LAMBDA_EXPR.
        (tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated
        substitution into a lambda-expr if we lost the template context.
        Add sanity check for error_mark_node result from begin_lambda_type.

gcc/testsuite/ChangeLog:

        * g++.dg/cpp2a/lambda-targ2.C: New test.
        * g++.dg/cpp2a/lambda-targ3.C: New test.
        * g++.dg/cpp2a/lambda-targ4.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[ppalka at gcc dot gnu.org]

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

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

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

commit r14-9943-d74fe10b13336b9de2e025ced4af00a25ff1d3e7
Author: Patrick Palka <ppalka@redhat.com>

c++: templated substitution into lambda-expr, cont [PR114393]

The original PR114393 testcase is unfortunately still not accepted after
r14-9938-g081c1e93d56d35 due to return type deduction confusion when a
lambda-expr is used as a default template argument.

The below reduced testcase demonstrates the bug.  Here when forming the
dependent specialization b_v<U> we substitute the default argument of F,
a lambda-expr, with _Descriptor=U.  (In this case in_template_context is
true since we're in the context of the template c_v, so we don't defer.)
This substitution in turn lowers the level of the lambda's auto return
type from 2 to 1 and so later, when instantiating c_v<int, char> we wrongly
substitute this auto with the template argument at level=0,index=0, i.e.
int, instead of going through do_auto_deduction which would yield char.

One way to fix this would be to use a level-less auto to represent a
deduced return type of a lambda, but that might be too invasive of a
change at this stage, and it might be better to do this across the board
for all deduced return types.

Another way would be to pass tf_partial from coerce_template_parms during
dependent substitution into a default template argument so that the
substitution doesn't do any level-lowering, but that wouldn't do the right
thing in this case due to the tf_partial early exit in the LAMBDA_EXPR
case of tsubst_expr.

Yet another way, and the approach that this patch takes, is to just
defer all dependent substitution into a lambda-expr, building upon the
logic added in r14-9938-g081c1e93d56d35.  This also helps ensure
LAMBDA_EXPR_REGEN_INFO consists only of the concrete template arguments
that were ultimately substituted into the most general lambda.

        PR c++/114393

gcc/cp/ChangeLog:

        * pt.cc (tsubst_lambda_expr): Also defer all dependent
        substitution.

gcc/testsuite/ChangeLog:

        * g++.dg/cpp2a/lambda-targ2a.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[ppalka at gcc dot gnu.org]

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

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

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

--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed, GCC trunk should now happily compile stdexec trunk, and our support for
lambdas as template arguments should be more robust to boot. thanks for the bug
report

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[prlw1 at cam dot ac.uk]

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

--- Comment #9 from Patrick Welche <prlw1 at cam dot ac.uk> ---
Thank you!

$ /usr/local/gcc/bin/g++ --version
g++ (GCC) 14.0.1 20240414 (experimental)
$ ./readme_ex
0 1 4