c++/3708: Zealous template expansion

[P Hornby]

In add_conversions (gcc/cp/search.c), add the cp_warning debug printouts
to the existing code

.......................
  for (i = 2; i < TREE_VEC_LENGTH (method_vec); ++i)
    {
      tree tmp = TREE_VEC_ELT (method_vec, i);
      tree name;

      if (!tmp || ! DECL_CONV_FN_P (OVL_CURRENT (tmp)))
	break;

      name = DECL_NAME (OVL_CURRENT (tmp));
      ////////////DEBUG///////////////
      cp_warning("add_conversions try %D, name = %D, marked = %d",
                 tmp,name,IDENTIFIER_MARKED (name));

      /* Make sure we don't already have this conversion.  */
      if (! IDENTIFIER_MARKED (name))
	{
           ///////////////DEBUG////////////////
           cp_warning("YUP");
	  *conversions = tree_cons (binfo, tmp, *conversions);
	  IDENTIFIER_MARKED (name) = 1;
	}
................

Compile WRONG2.c++ without options and note that Bar::operator T () [ T
= Foo ] succeeds
after BarBar::operator Foo () because the name marked by the latter is
"operator Foo" whereas the name marked by the former is "operator T".
While this
is not the cause of the current problem, (the ensuing joust several
frames up resolves the matter)
it and similar code elsewhere called by bfs_walk *may* be the cause of
bullish behaviour 
of the -fexternal-templates option (ie. bleeting about syntax errors in
base class templates that
do not need to be expanded because of current class overrides that match
exactly).

Suppose for a moment that it is better to deal with the matter here than
to put the issue
off until the sub-graph is embedded in something bigger, you know, to
minimise the risk
that a template may get expanded without syntax errors off, or to not
defeat bfs_walk, or just
for simple efficiency......

Is it safe in this context to suppose that if *a* conversion operator
has been found in a sub class
(and it will always be so for a bfs walk???) then it can ignore all base
class conversion templates, 
since they must all be of the form operator T (...) [T=something] for
the something already encountered?