generic type support

[C. van Reeuwijk]

> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
> 
> Andrew> I was thinking of writing a parser from scratch.  
> 
> I've been thinking about that too.
> 
> I've also thought about kidnapping Mark Mitchell and hypnotizing him
> to prefer Java to C++.
> 
> Andrew> However, after the reception the new C++ parser received, I'm
> Andrew> not sure.  In particular, accurate diagnostic messages and
> Andrew> good error recovery are tricky to get right, and any reduction
> Andrew> in the quality of error messages would be treated as a
> Andrew> regression, even if the perser was otherwise much better.
> 
> In our case, it seems like improved correctness would trump that.
> Plus, it's a low bar to start with.  There have been multiple PRs
> where gcj would ICE while trying to print an error message.  I think
> there is one like that open right now.  As long as we can flush stderr
> before crashing, we're ahead of the game.  :-)

Since you're so negative about your current frontend, you may want to
take a look at the parser and frontend I did for my own static compiler
for a superset of Java. It is contains a clean yacc parser for
Java 2 1.4.

See <www.pds.twi.tudelft.nl/timber>

Although the compiler compiles a superset of Java, the extensions are
only enabled for files with the special extension `.spar'. For .java
files it is a quite compiant Java compiler. At one point in time it had a
better score for the Jacks validation suite than Sun's own compiler(!).
Unfortunately, after that the Jacks people added lots of tests for all
those stupid restrictions on inner classes, and I couldn't be bothered
to keep up.

Performance was never much of a problem; the compiler generates
C++ code, and the compilation of the C++ code (using g++) is by far
the slowest part of the whole compilation.



-- 
Kees van Reeuwijk, Delft University of Technology
http://www.pds.twi.tudelft.nl/~reeuwijk