java/1306: Overriding method in Interface confuses gcj

java/1306: Overriding method in Interface confuses gcj

[mark]

>Number:         1306
>Category:       java
>Synopsis:       Overriding method in Interface confuses gcj
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apbianco
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:18:52 PST 2000
>Closed-Date:    Thu Oct 19 21:04:38 PDT 2000
>Last-Modified:  Thu Oct 19 21:16:01 PDT 2000
>Originator:     mark@klomp.org
>Release:        gcc version 2.96 20000714 (experimental)
>Organization:
>Environment:

>Description:
It is valid to override a method in a subinterface.
(Although only really usefull for documentation purposes.)
But gcj gets confused which method to call.

This does actually occur when trying to compile AbstractSet
from Classpath. (The workaround is to remove all methods
from the Set interface since all those methods are already
defined in Collection which is the super interface of Set.)

The following is the shortest example I could come up with:

public class A extends B implements I2 {
  public void m() {
      mi();
  }
}

abstract class B implements I {
  public void mi() {
  }
}

interface I {
  void mi();
}

interface I2 extends I {
  void mi();
}

$ gcj -C  A.java                       
A.java: In class `A':
A.java: In method `m()':
A.java:3: Can't find method `mi()' in type `A'. Candidates are:
  `mi()' in `I2'
  `mi()' in `B'.
      mi();
      ^
1 error
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Formerly PR gcj/285


From: Bryce McKinlay <bryce@albatross.co.nz>
To: mark@klomp.org
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Tue, 18 Jul 2000 11:01:57 +1200

 This is a multi-part message in MIME format.
 --------------26791560950A632C0C40BDF4
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 mark@klomp.org wrote:
 
 > >Description:
 > It is valid to override a method in a subinterface.
 > (Although only really usefull for documentation purposes.)
 > But gcj gets confused which method to call.
 >
 > This does actually occur when trying to compile AbstractSet
 > from Classpath. (The workaround is to remove all methods
 > from the Set interface since all those methods are already
 > defined in Collection which is the super interface of Set.)
 
 Thanks. This is actually a variant on PR234, which exposes a bug in the
 fix for that PR. I've attached a patch below.
 
 Possibly the test for "!max" should actually read "max", but that causes
 the PR234 test to fail. Alex: why does the call to
 valid_method_invocation_conversion_p from
 find_most_specific_methods_list return false for the PR234 test case?
 
 regards
 
   [ bryce ]
 
 
 --------------26791560950A632C0C40BDF4
 Content-Type: text/plain; charset=us-ascii;
  name="pr285.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="pr285.patch"
 
 2000-07-18  Bryce McKinlay  <bryce@albatross.co.nz>
 
 	* parse.y (find_most_specific_methods_list): Select the only 
 	non-abstract method even if max has been set.
 
 Index: parse.y
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
 retrieving revision 1.192
 diff -u -r1.192 parse.y
 --- parse.y	2000/07/13 19:27:49	1.192
 +++ parse.y	2000/07/17 22:44:31
 @@ -10325,7 +10325,7 @@
  
    /* We have several, we couldn't find a most specific, all but one are
       abstract, we pick the only non abstract one. */
 -  if (candidates > 0 && !max && (candidates == abstract+1))
 +  if (candidates > 0 && (candidates == abstract+1))
      {
        for (current = new_list; current; current = TREE_CHAIN (current))
  	if (!METHOD_ABSTRACT (TREE_VALUE (current)))
 
 --------------26791560950A632C0C40BDF4--
 

From: Mark Wielaard <mark@klomp.org>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Tue, 18 Jul 2000 10:55:11 +0200

 Hi,
 
 On Tue, Jul 18, 2000 at 11:01:57AM +1200, Bryce McKinlay wrote:
 > Thanks. This is actually a variant on PR234, which exposes a bug in the
 > fix for that PR. I've attached a patch below.
 
 Yeah! That works for me.
 Now the only real showstopper for compiling the Collection classes
 from Classpath seems to be gcj/257.
 
 Thanks,
 
 Mark

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Tue, 26 Sep 2000 12:21:36 -0700 (PDT)

 Bryce McKinlay writes:
 
 >  Possibly the test for "!max" should actually read "max", but that
 >  causes the PR234 test to fail.
 
 We shouldn't be using max at all. We don't have a most specific
 method, max could have any value, including 0. I believe your patch is
 correct.
 
 > Alex: why does the call to valid_method_invocation_conversion_p from
 > find_most_specific_methods_list return false for the PR234 test
 > case?
 
 Well, we have:
 
 	B
         |
         A ... I
 
 We have two candidates: B.m() and I.m() and we go by the method
 invocation conversion rules (5.3, especially 5.1.4 in our case because
 we have references.) B can't be converted to I because B doesn't
 implement I. I can't be converted to B because B isn't Object.
 
 By the way, I don't see 234 failing with your patch applied.
 
 ./A

From: Bryce McKinlay <bryce@albatross.co.nz>
To: apbianco@redhat.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Wed, 27 Sep 2000 12:12:21 +1200

 Alexandre Petit-Bianco wrote:
 
 > Bryce McKinlay writes:
 >
 > >  Possibly the test for "!max" should actually read "max", but that
 > >  causes the PR234 test to fail.
 >
 > We shouldn't be using max at all. We don't have a most specific
 > method, max could have any value, including 0. I believe your patch is
 > correct.
 
 OK. Shall I consider it approved?
 
 regards
 
   [ bryce ]
 
 

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Tue, 26 Sep 2000 17:27:01 -0700 (PDT)

 Bryce McKinlay writes:
 
 > OK. Shall I consider it approved?
 
 I'd like to run tests with it. I'll do that once I fix a nasty problem
 that I found with the compilation of Hashtable.
 
 ./A
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Thu Oct 19 21:04:38 2000
State-Changed-Why:
    I checked in a patch:
      http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00646.html

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/285: Overriding method in Interface confuses gcj
Date: Thu, 19 Oct 2000 21:02:53 -0700 (PDT)

 Alexandre Petit-Bianco writes:
 
 >  I'd like to run tests with it. I'll do that once I fix a nasty
 >  problem that I found with the compilation of Hashtable.
 
 Well, the Hashtable problem is caused by something else. I checked in
 Bryce's fix and I'm going to close this PR:
 
   http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00646.html
 
 ./A

From: apbianco@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com, mark@klomp.org
Cc:  
Subject: Re: gcj/285
Date: 20 Oct 2000 04:04:38 -0000

 Synopsis: Overriding method in Interface confuses gcj
 
 State-Changed-From-To: open->closed
 State-Changed-By: apbianco
 State-Changed-When: Thu Oct 19 21:04:38 2000
 State-Changed-Why:
     I checked in a patch:
       http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00646.html
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=285&database=java
>Unformatted: