PR java/21436: imported type name for superclass, with multifile compilation

[Paolo Bonzini]

The patch fully implements section 6.5.5.1, item 4, of the Java Language 
Specification (thanks to Andrew Haley for the pointer): "If a type with 
that name is declared in the current compilation unit [by] a 
single-type-import declaration [...], then the simple type name denotes 
that type".  If multifile compilation is active, the subclass is 
compiled but the superclass is not, and the subclass specifies the 
superclass with a simple type name, then gcj will not be able to find 
the superclass.

The simplest failure mode was that of PR21436, but several others are 
exposed by my patch to compile libjava one directory at a time.  In 
order to fix them, several actions are needed:

1) the first and most important is to really implement section 6.5.5.1/4 
in do_resolve_class, find_in_imports and find_in_imports_demand.

2) quite surprisingly for me, the compilation units are processed in 
reverse order during pass 2 and 3.  The problem is that, if both class
X and class Y are on the command line (like gcj "X.java Y.java"), and X 
extends Y, read_class will do a java_pop_parser_context for Y before the 
parsing of X is finished: so, unless classes are tacked to the *tail* of 
the ctxp_for_generation linked list, subsequent passes through 
ctxp_for_generation will process X before Y.

3) the TYPE_IMPORT_LIST and TYPE_IMPORT_DEMAND_LIST are currently set at 
the beginning of phase 2.  The problem is that phase 2 is done *before* 
completing the parsing of the files on the command line, if gcj needs to 
shuffle the order of files given on the command line.  So, take this 
hierarchy


   _______________
  |               |
  |   JComponent  |
  |_______________|
          |
   _______V_______
  |               |
  |    JButton    |
  |_______________|
          |
   _______V_______
  |               |
  | JToggleButton |
  |_______________|

and a command line like "gcj JComponent.java JToggleButton.java 
JButton.java".  Now gcj executes:
   - phase 1 for JToggleButton
   - phase 1 for JButton
     - phase 1 for JButton
     - phase 2 for JButton (**)
     - phase 3 for JButton (**)
     - then, phase 1 is finished for JButton
   - phase 2 for JComponent (++)
   - phase 3 for JComponent
   - phase 2 for JToggleButton
   - phase 3 for JToggleButton

and the phases marked (**) won't see the TYPE_IMPORT_LIST and 
TYPE_IMPORT_DEMAND_LIST of JComponent, which are only set at time (++).

All these fixes are necessary.  PR21236 works if you apply only fix #2 
and part of fix #1 (only the change to find_in_imports), or fixes #1 and 
#3.  PR21242 on the other hand needs the complete fix for #1, and #3 
too.  The case I just described with Swing classes, finally, requires 
all the fixes (it is also the only one to involve three files on the 
command line, rather than just two).

Tested with my Makefile patch and without it on mainline, bootstrapping 
C/C++/Java and regtesting Java only (no new failures).  Ok?  I won't 
propose this for 4.0, but it could reasonably go there after it's been 
on mainline for a while.

Paolo

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: java-fix-import-bugs.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20050510/ab8da7c8/attachment.ksh>