Templates
=========

   A template is represented by a `TEMPLATE_DECL'.  The specific fields
used are:

`DECL_TEMPLATE_RESULT'
     The generic decl on which instantiations are based.  This looks
     just like any other decl.

`DECL_TEMPLATE_PARMS'
     The parameters to this template.

   The generic decl is parsed as much like any other decl as possible,
given the parameterization.  The template decl is not built up until the
generic decl has been completed.  For template classes, a template decl
is generated for each member function and static data member, as well.

   Template members of template classes are represented by a
TEMPLATE_DECL for the class' parameters around another TEMPLATE_DECL
for the member's parameters.

   All declarations that are instantiations or specializations of
templates refer to their template and parameters through
DECL_TEMPLATE_INFO.

   How should I handle parsing member functions with the proper param
decls?  Set them up again or try to use the same ones?  Currently we do
the former.  We can probably do this without any extra machinery in
store_pending_inline, by deducing the parameters from the decl in
do_pending_inlines.  PRE_PARSED_TEMPLATE_DECL?

   If a base is a parm, we can't check anything about it.  If a base is
not a parm, we need to check it for name binding.  Do
finish_base_struct if no bases are parameterized (only if none,
including indirect, are parms).  Nah, don't bother trying to do any of
this until instantiation - we only need to do name binding in advance.

   Always set up method vec and fields, inc. synthesized methods.
Really?  We can't know the types of the copy folks, or whether we need a
destructor, or can have a default ctor, until we know our bases and
fields.  Otherwise, we can assume and fix ourselves later.  Hopefully.