[Bug c++/105268] type/value mismatch when using variadic concept

2022-04-15 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 12.

[Bug c++/105268] type/value mismatch when using variadic concept

2022-04-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-8176-gccae4443c8322d9d82a19a1e7c689413a122a478
Author: Marek Polacek 
Date:   Thu Apr 14 13:48:15 2022 -0400

c++: wrong error with variadic concept [PR105268]

Here we issue a wrong error for the

  template>> void g();

line in the testcase.  I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there.  We are in a default argument so we should reject parsing
C_many
as a placeholder-type-specifier, which would mean creating a new parameter.
We want C_many to be a concept-id instead.

It's interesting to see why the same problem didn't occur for C_one.
In that case, cp_parser_placeholder_type_specifier ->
finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms fails the parse here:

 8916   nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
 8917   if ((nargs - variadic_args_p > nparms && !variadic_p)
 8918   || (nargs < nparms - variadic_p
 8919   && require_all_args
 8920   && !variadic_args_p
 8921   && (!use_default_args
 8922   || (TREE_VEC_ELT (parms, nargs) != error_mark_node
 8923   && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
 8924 {
 8925 bad_nargs:
 ...
 8943   return error_mark_node;

because nargs is 2 (the targs are ) while nparms is
1 (for the one 'typename' in the tparam list of C_one).  But for
C_many variadic_p is true so we don't return error_mark_node but
.

This patch does not issue any error for the !tentative case because
I didn't figure out how to trigger that.  So it adds an assert instead.

PR c++/105268

gcc/cp/ChangeLog:

* parser.cc (cp_parser_placeholder_type_specifier): Return
error_mark_node when trying to build up a constrained parameter in
a default argument.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/variadic6.C: New test.

[Bug c++/105268] type/value mismatch when using variadic concept

2022-04-14 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c++/105268] type/value mismatch when using variadic concept

2022-04-13 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268

--- Comment #2 from Marek Polacek  ---
Looks like we mistakenly parse C_many as a placeholder-type-specifier, and
things go wrong from there.

For C_one cp_parser_placeholder_type_specifier -> finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms -> coerce_template_parms fails here:

 8916   nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
 8917   if ((nargs - variadic_args_p > nparms && !variadic_p)
 8918   || (nargs < nparms - variadic_p
 8919   && require_all_args
 8920   && !variadic_args_p
 8921   && (!use_default_args
 8922   || (TREE_VEC_ELT (parms, nargs) != error_mark_node
 8923   && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
 8924 {
 8925 bad_nargs:

but for C_many variadic_p is true so we don't return error_mark_node but
.

[Bug c++/105268] type/value mismatch when using variadic concept

2022-04-13 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2022-04-13
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.