This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] [PR2204] Check for parameters of abstract types(partial fix) - Take 2
- From: Jason Merrill <jason at redhat dot com>
- To: "Giovanni Bajo" <giovannibajo at libero dot it>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 30 Apr 2004 17:54:47 -0400
- Subject: Re: [C++ PATCH] [PR2204] Check for parameters of abstract types(partial fix) - Take 2
- References: <1c9c01c3ef6c$71c10f10$9cba2997@bagio><m3vfmf3ctv.fsf@uniton.integrable-solutions.net><1d8201c3ef7f$41471b50$9cba2997@bagio><m3bro73bft.fsf@uniton.integrable-solutions.net><1f3901c3effc$90c19a70$9cba2997@bagio>
On Tue, 10 Feb 2004 18:37:31 +0100, "Giovanni Bajo" <giovannibajo@libero.it> wrote:
> Alas, this solution is partial, mainly because it doesn't get into account
> array types. In fact, parameters with array type are decayed into pointer types
> within grokdeclarator (even before a PARM_DECL is built), so they never get
> registered into the incomplete_vars list. A solution for this might be
> extracting the standard decays out of grokdeclarator, and having grokparms call
> it. There is also another user of grokdeclarator(PARM) (in pt.c, to build
> template parameters), which should be updated as well. Comments on this plan
> are highly appreciated.
There's a much simpler solution: just check for abstract types in
create_array_type_for_decl.
8.3.4 Arrays [dcl.array]
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.
This should also make strip_array_and_pointer_to_array_types unnecessary.
> Another case we don't handle yet is when the type of the parameter is
> dependent. In that case, we probably need to check for abstractness upon
> instantiation, while tsubsting. I'll investigate.
Please.
Jason