groovy
  1. groovy
  2. GROOVY-4016

Single super constructor argument is casted to array if super constructor has vararg parameter

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.0
    • Fix Version/s: 2.0.0, 1.8.7
    • Component/s: Compiler
    • Labels:
      None
    • Number of attachments :
      0

      Description

      class Foo {
        def Foo(String... s) { }
      }
      class ImplOneParameter extends Foo {
        def ImplOneParameter(String s) {
          super(s)
        }
      }
      class ImplArray extends Foo {
        def ImplArray(String[] s) {
          super(s)
        }
      }
      
      
      new ImplArray("String")
      new ImplOneParameter("String") //fails with CCE
      

      The same dispatch as for usual method calls should apply.

        Issue Links

          Activity

          Hide
          Roshan Dawrani added a comment -

          Jochen, I am a bit skeptical about making changes without clearly understanding exactly what is happening in MC#selectConstructorAndTransformArguments() and why. I don't want to break more than I make there. There are too many small-small bits I don't understand in that method - like the sorting based on type descriptors, role of index of constructor chosen, etc. If I don't clearly get the current picture of it, I will give this issue a pass most probably.

          In that case, do you think it will be better to undo 4015 and go back to ClassCastExceptions? Or, can that fix be kept so that at least we are half-way there in supporting this()/super() with non-matching argument/parameter types? It's only in corner cases like var arg usage here that behavior may be buggy until 4016 gets solved properly.

          If you think it will be better to go pre-4015 state, I can just undo that for now.

          Show
          Roshan Dawrani added a comment - Jochen, I am a bit skeptical about making changes without clearly understanding exactly what is happening in MC#selectConstructorAndTransformArguments() and why. I don't want to break more than I make there. There are too many small-small bits I don't understand in that method - like the sorting based on type descriptors, role of index of constructor chosen, etc. If I don't clearly get the current picture of it, I will give this issue a pass most probably. In that case, do you think it will be better to undo 4015 and go back to ClassCastExceptions? Or, can that fix be kept so that at least we are half-way there in supporting this()/super() with non-matching argument/parameter types? It's only in corner cases like var arg usage here that behavior may be buggy until 4016 gets solved properly. If you think it will be better to go pre-4015 state, I can just undo that for now.
          Hide
          blackdrag blackdrag added a comment -

          I think it is probably best to undo 4015 and make it a duplicate of this one

          Show
          blackdrag blackdrag added a comment - I think it is probably best to undo 4015 and make it a duplicate of this one
          Hide
          Roshan Dawrani added a comment -

          Sounds good. I will do that.

          Show
          Roshan Dawrani added a comment - Sounds good. I will do that.
          Hide
          Roshan Dawrani added a comment -

          Jochen, I have undone the fix of 4015 and marked that as duplicate of this one.

          When this issue is fixed, it must be ensured that GROOVY-4015 scenario is handled as well. Probable the testcase can be reused later from MethodSelectionTest.groovy's history.

          Sorry about a little mess that I have created here, but I had no idea about 4016 when I was working on 4015

          Show
          Roshan Dawrani added a comment - Jochen, I have undone the fix of 4015 and marked that as duplicate of this one. When this issue is fixed, it must be ensured that GROOVY-4015 scenario is handled as well. Probable the testcase can be reused later from MethodSelectionTest.groovy's history. Sorry about a little mess that I have created here, but I had no idea about 4016 when I was working on 4015
          Hide
          blackdrag blackdrag added a comment -

          this issues seems to be fixed since 1.8.0

          Show
          blackdrag blackdrag added a comment - this issues seems to be fixed since 1.8.0

            People

            • Assignee:
              blackdrag blackdrag
              Reporter:
              Peter Gromov
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: