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.
Created attachment 57736 [details] Gzipped preprocessed source Bisecting ...
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.
Reducing ...
This might come down to: ``` template <class _Descriptor, auto t = [] { return _Descriptor();}> inline constexpr auto __descriptor_fn_v = t; ``` being handled wrong.
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 ...
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>
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>
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
Thank you! $ /usr/local/gcc/bin/g++ --version g++ (GCC) 14.0.1 20240414 (experimental) $ ./readme_ex 0 1 4