This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]