🚀 go-pugleaf

	You need to do the whole job because of typedefs.  I.e.,

		typedef int foo;
		typedef int bar;

		foo f (bar);

I was thinking that in the "function specification language", typedefs
in this sense would not be allowed. Even though foo might be declared

foo f(bar);

in some source code, it would have to be declared

int f(int)

in a function specification to be accepted by the mangler. Note that
there are other differences between this function specification
language and C++.  For instance, 

class Foo  {
  int foo(Foo*);
};

int Foo::foo(Foo*);

isn't a valid declaration in C++. (Oooh, speaking of valid C++, note
that the above is accepted by g++-1.39 but not by cfront 2.0--bug?.)
I was thinking that any identifier (name other than reserved words,
symbols, or basic types) would be assumed to directly name a user
defined type.  Typedefed aliases or full anonymous struct definitions
would not be accepted.

It seems clear that one requirement would be that the mangler be able
to accept any output generated by the demangler and vice versa. I
think the simplifications I'm making are consistent with that. However
it's not clear what other requirements exist for a useful tool. For
instance, these specs would not necessarily let you directly use
pieces of source code or output from the compiler as input to the
mangler. I don't see any way of creating such a mangler without
analyzing the entire source code for a module and that's significantly
more work than I want the mangler to do. Aside from compilation, it
seems the reason most people have cited for wanting a mangler is for
dynamic loading. I'm not sure if these simplifications would
adequately support that.