[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #9 from Patrick Welche --- Thank you! $ /usr/local/gcc/bin/g++ --version g++ (GCC) 14.0.1 20240414 (experimental) $ ./readme_ex 0 1 4
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #7 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d74fe10b13336b9de2e025ced4af00a25ff1d3e7 commit r14-9943-d74fe10b13336b9de2e025ced4af00a25ff1d3e7 Author: Patrick Palka 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 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 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
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #6 from Patrick Palka --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917 commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917 Author: Patrick Palka 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) : Stream LAMBDA_EXPR_EXTRA_ARGS. (trees_in::core_vals) : 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
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Jeffrey A. Law 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Patrick Palka 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
--- Comment #5 from Andrew Pinski ---
Reduced testcase which shows this never worked:
```
template struct c1 {};
template
inline constexpr auto b_v = t;
template
using c1_t = c1>;
template
constexpr auto g(_Data __data) {
return c1_t<_Data>{};
}
void f() {
auto & = 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Andrew Pinski changed: What|Removed |Added Keywords||c++-lambda --- Comment #4 from Andrew Pinski --- This might come down to: ``` template 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 --- Comment #3 from Andrew Pinski --- Reducing ...
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||rejects-valid
