[C++ PATCH] [PR2204] Check for parameters of abstract types - Take 3
Jason Merrill
jason@redhat.com
Mon Jun 14 22:12:00 GMT 2004
On Sun, 13 Jun 2004 01:05:16 -0700, Mark Mitchell <mark@codesourcery.com> wrote:
> Giovanni Bajo wrote:
>
>>Jason Merrill wrote:
>>>There's a much simpler solution: just check for abstract types in
>>>create_array_type_for_decl.
>>
>>I tried this but it occurred to me that if I checked for abstract types in
>>grokdeclarator immediatly after the big loop where the type for the declaration
>>is constructed (and where create_array_type_for_decl is called for the
>>ARRAY_REF case), I could catch both the array and the non-array case at the
>>same time, unifying the check. In fact, it works beautifully, so I removed the
>>other check for abstractness from grokparms. The only quirk is that I need to
>>create a PARM_DECL just for the purpose of storing it in the incomplete_vars
>>list (it cannot be done with the real PARM_DECL because that's already decayed
>>from array to pointer), but it doesn't seem too much of a problem to me.
>>
> It is a problem -- DECLs are big, and so creating extra DECLs is a problem.
>
> We should find another way.
I suggested another way. It is in fact a constraint violation to have an
array of abstract types regardless of where it appears, so we really should
be checking in create_array_type_for_decl regardless of what we do for
parms.
8.3.4 Arrays [dcl.array]
1 In a declaration T D where D has the form
D1 [constant-expressionopt]
and the type of the identifier in the declaration T D1 is "derived-
declarator-type-list T," then the type of the identifier of D is an
array type. T is called the array element type; this type shall not
be a reference type, the (possibly cv-qualified) type void, a function
type or an abstract class type.
Jason
More information about the Gcc-patches
mailing list