This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR c++/20172: Invalid non-type template parametersnot diagnosed
On 10 Jun, Nathan Sidwell wrote:
> Volker Reichelt wrote:
>
> > 2005-06-10 Volker Reichelt <reichelt@igpm.rwth-aachen.de>
> >
> > PR c++/20172
> > * pt.c (tsubst_template_parms): Check for invalid non-type parameters.
> >
> > ===================================================================
> > --- gcc/gcc/cp/pt.c 2005-04-08 21:36:01.000000000 +0200
> > +++ gcc/gcc/cp/pt.c 2005-06-09 01:13:03.000000000 +0200
> > @@ -5962,6 +5962,9 @@ tsubst_template_parms (tree parms, tree
> > tree parm_decl = TREE_VALUE (tuple);
> >
> > parm_decl = tsubst (parm_decl, args, complain, NULL_TREE);
> > + if (TREE_CODE (parm_decl) != TEMPLATE_DECL)
> > + invalid_nontype_parm_type_p (TREE_TYPE (parm_decl), complain);
> > +
> > default_value = tsubst_template_arg (default_value, args,
> > complain, NULL_TREE);
>
> why ignore the return value from invalid_nontype_parm_type_p?
Because the above solution seemed to be the fastest and least
intrusive one.
I tried returning an error_mark_node. This requires some more checks
for error_mark_nodes (which will cause slight slowdowns of the compiler)
with no real benefit: the error messages are still the same.
In addition I might have missed some checks for error_mark_nodes
risking ice-on-invalid-code regressions.
> How are type parms not checked here (aren't they TYPE_DECL).
Their tree code is TEMPLATE_TYPE_PARM which is accepted by
invalid_nontype_parm_type_p.
I don't know what's faster here: The version above where we check
for the relatively common TEMPLATE_TYPE_PARM late in
invalid_nontype_parm_type_p. Or adding a check for TEMPLATE_TYPE_PARM
before we enter invalid_nontype_parm_type_p as a fast path for
type parms (with a duplicte test for TEMPLATE_TYPE_PARM).
> I can look in more detail next week.
Thanks!
Btw, I wrongly blamed my patch for duplicate error messages in case
of nested classes. In fact, the duplicate messages have been there
since GCC 3.3. With GCC 3.2.x the compiler even goes into an infinite
loop.
Regards,
Volker