Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

[Richard Guenther <rguenther at suse dot de>]

On Thu, 30 Nov 2006, Mark Mitchell wrote:

> Richard Guenther wrote:
> > This patch is the Nth try to attack the problems around 
> > classtype_mangled_name and the testcase in PR29433 which happens to
> > use 1GB of identifiers:
> 
> Nice patch.
> 
> As an FYI, mangle_class_name_for_template has nothing to do with
> name-mangling, in the usual sense.  It's a misnamed routine.  (I've
> vaguely meant to rename for about ten years.)  It's actual job is to
> create human-readable names for class template specializations.
> 
> Semantically, you should be able to completely remove this routine, and
> not see any testsuite failures.  If that were to cause problems, then
> we've got something depending on names that shouldn't depend on that at
> all.

Unfortunately name-lookup depends on DECL_NAME being distinct for two
classtypes in certain circumstances (it's a mystery to me where exactly).
So you get a lot of name-lookup related testsuite failures if you for 
example remove the special casing and just do

static tree
classtype_mangled_name (tree t)
{
  return TYPE_IDENTIFIER (t);
}

(TYPE_IDENTIFIER will have the base class name).  Maybe someone familiar
with the C++ frontend can disentangle name-lookup from DECL_NAME...

> I bet the only place where we use the value computed is in generating
> debugging information, as the name of a class template specialization.
> We may also use it when printing error messages, but that machinery can
> print template arguments itself, so it should be easy to avoid needing
> it just for diagnostics.
> 
> So, if you want an even bigger win: arrange to have the debugging
> information callback to the front end when it actually needs the pretty
> name.  One mechanism would be a hook that is called for all types to
> return a name; by default, or if the hooks is NULL, it just returns
> DECL_NAME.

My initial idea was to defer creating DECL_NAME to the diagnostic or
debugging and there even use a mangled name to save space in the debug
info.  But with the name-lookup issues not fixed this turned out to
be impractical.
 
> However, I think the idea of your patch is fine -- if you ensure that
> the error-message machinery doesn't use this value.  The reason I thin
> that's important is that if the user does:
> 
> template <int I>
> void f() {
>   ... C<I> ... // error here
> }
> 
> and gets an error about "C<J>" that's very confusing -- especially if
> there's another "J" in scope.  I like the EDG approach of saying "C<#1>
> [#1 = I]" in this kind of situation.

I didn't see the identifiers used in error messages - but the search
was not exhaustive of course.  Any idea on how to increase testing
coverage here appreciated.

Thanks,
Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs