[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