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

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

>   FAIL: 15.12.2.1-accessibility-method-2
>   FAIL: 15.12.2.1-accessibility-method-4
>   XPASS: 15.12.2.1-accessibility-method-3
>   XPASS: 15.12.2.1-accessibility-method-5

Yes, I had just found these.  Thanks for doing the testing for me, 
however; and again, thanks very much to Andrew and Tom for the help they 
gave me.

I am all but a Java language lawyer, but I don't see how in practice one 
could derive a concrete class from the testcase in jacks:

abstract class T151221am2a { abstract void m(); }
interface T151221am2b { void m() throws Exception; }
public abstract class T151221am2c
   extends T151221am2a implements T151221am2b { }

I could stare at the JLS for a while, but how can you define *both* 
"m()" and "m() throws Exception" in a concrete subclass?

The important part, however, as Andrew pointed out on IRC, is that my 
patch has merely exposed this bug rather than caused it.  With mainline 
gcj, all four testcases fail to compile with this pretty cryptic error:

class p1.T151221am2a interface p1.T151221am2b class p1.T151221am2c class 
T151221am2d class p1.T151221am2aT151221am2c.java:2: fatal error: reading 
class p1.T151221am2a for the second time from
compilation terminated.

With my patch, all four compile successfully, even the invalid ones.

Instead, if you invert the order of the two files in the testcase, the 
result is the opposite.  With my patch, the testcases fail to compile 
with the same error; without my patch, all four compile successfully.

This failure mode makes sense actually, since my patch modifies the 
order in which phases 2 and 3 are performed on the input files.

Is my patch ok for mainline with an appropriate change to jacks.xfail?

Thanks,

Paolo