[ nice-Bugs-1509635 ] Nicec should deal with covariant return types properly

Bugs item #1509635, was opened at 2006-06-21 03:32
Message generated for change (Settings changed) made by artemgr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=1509635&group_id=12788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: B S (ben77)
>Assigned to: Artem Gr Kozarezov (artemgr)
Summary: Nicec should deal with covariant return types properly

Initial Comment:
Currently nicec looks at bridge methods when evaluating
possible methods for a call. This leads to confusing
error messages under 1.5 like the ones about
StringBuffer that prevent nice from compiling under
1.5. For example:

package testing;

void main(String[] args) 
{
  StringBuffer buf = new StringBuffer();
  buf.append("a").append('A');
}

Fails to compile with this error:
nice.lang: parsing
testing: parsing
testing: typechecking

~/test/nice/testing/main.nice:6:19:
Ambiguity for symbol append. Possibilities are :
java.lang.AbstractStringBuilder
append(java.lang.AbstractStringBuilder, ?Object)
java.lang.Appendable append(java.lang.Appendable,
nice.lang.char)
compilation failed with 1 error

Neither of these methods should be visible, as they are
overridden by StringBuffer.

----------------------------------------------------------------------

Comment By: Artem Gr Kozarezov (artemgr)
Date: 2006-10-11 16:39

Message:
Logged In: YES 
user_id=289741

Ben, thank you very much for your effort!
With your patch I was able to bootstrap the Nice compiler
under the Sun JDK build 1.6.0-rc-b101.

Your patch is in CVS.
The version bootstrapped under JVM6 is available as
http://nice.sourceforge.net/nice-current.jar

Sorry for the delay.

----------------------------------------------------------------------

Comment By: B S (ben77)
Date: 2006-06-21 07:57

Message:
Logged In: YES 
user_id=929365

Yeah, its not bridge methods, its that in 1.5 you can have
covariant return types, and therefore to check if two
methods are exactly equivalent you need to check return
types too. bossa.syntax javaMethod.nice/alreadyHasMethod
doesn't do this, so StringBuffer StringBuffer.append(String)
gets dropped in favor of AbstractStringBuilder
AbstractStringBuffer.append(String), even though the return
types are different. Fixing this requires changing
alreadyHasMethod to check return types. It (maybe, there is
probably a better way) also requires changing findBaseMethod
to check the whole superclass hierarchy and all of their
interfaces with alreadyHasMethod since it could be
reoverriding the return type (AbstractStringBuilder
overrides Appendable's, but StringBuffer overrides ASB's, so
it needs to check Appendable StringBuffer.append(char)
against everything). This could probably be done more
efficiently (push tuples of the data into a hashset and
check there or something?), but I'm too tired to think
straight now.

The testsuite passes (regtest fails with a parser error
about a bad character with or w/o the patch)

I'm attaching a patch of my current changes, including all
my debugging stuff. Hopefully I'll clean it up tommorrow.

----------------------------------------------------------------------

Comment By: B S (ben77)
Date: 2006-06-21 04:45

Message:
Logged In: YES 
user_id=929365

Actually, looking this over, it looks like its not bridge
methods exactly, although it may be related.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=1509635&group_id=12788

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642