X10

X10 should catch ambiguous methods better

Details

  • Number of attachments :
    1

Description

Look at the class Boom[X,Y]. It's got two methods with the same name, distinguised by argument type: one for X, one for Y.

Look at the main program, where X == Y == Int.

X10 ought to detect this. It doesn't. Java does.

public class Crasher {
  public static def main(argv:Rail[String]) {
    val b:Boom[Int,Int]! = new Boom[Int,Int]();
    x10.io.Console.OUT.println("b.boom(1) = " + b.boom(1));
  }
}

class Boom[X,Y] {
  def boom(x:X) = 1;
  def boom(y:Y) = 2;

}

Compiler output:

x10c: ----------
1. ERROR in /Users/bard/x10/exper/Crasher.java (at line 80)
java.lang.String.valueOf((b).boom(1)));
^^^^
The method boom(int) is undefined for the type Boom<Integer,Integer>
----------
2. ERROR in /Users/bard/x10/exper/Crasher.java (at line 125)
boom(
final X x){
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Method boom(X) has the same erasure boom(Object) as another method in type Boom<X,Y>
----------
3. ERROR in /Users/bard/x10/exper/Crasher.java (at line 135)
boom(
final Y y){
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Method boom(Y) has the same erasure boom(Object) as another method in type Boom<X,Y>
----------
3 problems (3 errors)

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-978 Inheriting two instantiations of the same method?

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-978 Inheriting two instantiations of the same method?

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-547 Front-end fails to reject method overloading on constrained types (place types)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Igor Peshansky added a comment -

This should be caught when one tries to instantiate Boom[Int,Int], not when Boom is defined.

Show
Igor Peshansky added a comment - This should be caught when one tries to instantiate Boom [Int,Int] , not when Boom is defined.
Hide
Permalink
Bard Bloom added a comment -

Or perhaps even when one attempts to call b.boom(1), depending on the intended semantics. It shouldn't go all the way to Java anyhow.

Show
Bard Bloom added a comment - Or perhaps even when one attempts to call b.boom(1) , depending on the intended semantics. It shouldn't go all the way to Java anyhow.
Hide
Permalink
Vijay Saraswat added a comment -

Should probably be caught when the class Boom is defined (as in Java) – this is a very flaky idiom to use in X10.

(Moved out to 2.1 simply based on available resources.)

Show
Vijay Saraswat added a comment - Should probably be caught when the class Boom is defined (as in Java) – this is a very flaky idiom to use in X10. (Moved out to 2.1 simply based on available resources.)
Hide
Permalink
David Grove added a comment -

defer all non-critical X10 issues to 2.1.0.

Show
David Grove added a comment - defer all non-critical X10 issues to 2.1.0.
Hide
Permalink
Igor Peshansky added a comment -

This a similar issue to XTENLANG-978 – the two methods should be presumed different unless proven to be the same (i.e., at instantiation time). The implementation techniques for the Java backend will be the same. The methods are distinct in X10, and we should not dumb down the language because of difficulties in implementation.

Show
Igor Peshansky added a comment - This a similar issue to XTENLANG-978 – the two methods should be presumed different unless proven to be the same (i.e., at instantiation time). The implementation techniques for the Java backend will be the same. The methods are distinct in X10, and we should not dumb down the language because of difficulties in implementation.
Hide
Permalink
Igor Peshansky added a comment -

This cannot be fixed until the Java backend can support the two definitions of boom in the same generic class.

Show
Igor Peshansky added a comment - This cannot be fixed until the Java backend can support the two definitions of boom in the same generic class.
Hide
Permalink
Igor Peshansky added a comment -

Bulk defer all non-critical, non-blocker frontend issues to 2.1.0.

Show
Igor Peshansky added a comment - Bulk defer all non-critical, non-blocker frontend issues to 2.1.0.
Hide
Permalink
Yuki Makino added a comment -

Added support for the two definitions in the same generic class in the Java back-end.

Show
Yuki Makino added a comment - Added support for the two definitions in the same generic class in the Java back-end.
Hide
Permalink
David Grove added a comment -

bulk defer of unresolved 2.1.0 bugs to 2.1.1.

Show
David Grove added a comment - bulk defer of unresolved 2.1.0 bugs to 2.1.1.
Hide
Permalink
David Grove added a comment -

bulk move of all unresolved issues from 2.1.1 to 2.1.2

Show
David Grove added a comment - bulk move of all unresolved issues from 2.1.1 to 2.1.2
Hide
Permalink
David Grove added a comment -

defer all non-critical 2.1.2 issues to 2.2.

Show
David Grove added a comment - defer all non-critical 2.1.2 issues to 2.2.
Hide
Permalink
Igor Peshansky added a comment -

This is currently caught by the compiler when attempting to invoke b.boom(1):

./Crasher.x10:4: Multiple methods match boom(x10.lang.Int{self==1}) [method Boom.boom(x: x10.lang.Int), method Boom.boom(y: x10.lang.Int)]
1 error.

Not ideal, but we will have to live with that for 2.2. We'll do something better for 2.2.1.

Show
Igor Peshansky added a comment - This is currently caught by the compiler when attempting to invoke b.boom(1) : ./Crasher.x10:4: Multiple methods match boom(x10.lang.Int{self==1}) [method Boom.boom(x: x10.lang.Int), method Boom.boom(y: x10.lang.Int)] 1 error. Not ideal, but we will have to live with that for 2.2. We'll do something better for 2.2.1.
Hide
Permalink
David Grove added a comment -

bulk defer of open issues to 2.2.2.

Show
David Grove added a comment - bulk defer of open issues to 2.2.2.
Hide
Permalink
David Grove added a comment -

bulk defer of issues to 2.2.3.

Show
David Grove added a comment - bulk defer of issues to 2.2.3.
Hide
Permalink
David Grove added a comment -

bulk defer of 2.3.0 open issues to 2.3.1.

Show
David Grove added a comment - bulk defer of 2.3.0 open issues to 2.3.1.
Hide
Permalink
David Grove added a comment -

bulk defer to 2.3.2

Show
David Grove added a comment - bulk defer to 2.3.2

People

  • Assignee:
    Unassigned
    Reporter:
    Bard Bloom
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:

Time Tracking

Estimated:
4d
Original Estimate - 4 days
Remaining:
4d
Remaining Estimate - 4 days
Logged:
Not Specified
Time Spent - Not Specified