X10
  1. X10
  2. XTENLANG-741

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          David Grove added a comment -

          bulk defer to 2.3.2

          Show
          David Grove added a comment - bulk defer to 2.3.2
          Hide
          David Grove added a comment -

          bulk defer to 2.4.1.

          Show
          David Grove added a comment - bulk defer to 2.4.1.
          Hide
          David Grove added a comment -

          bulk defer to 2.4.2

          Show
          David Grove added a comment - bulk defer to 2.4.2
          Hide
          David Grove added a comment -

          bulk defer to 2.4.3

          Show
          David Grove added a comment - bulk defer to 2.4.3
          Hide
          David Grove added a comment -

          bulk defer to 2.4.4

          Show
          David Grove added a comment - bulk defer to 2.4.4

            People

            • Assignee:
              Unassigned
              Reporter:
              Bard Bloom
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

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