Scala Programming Language
  1. Scala Programming Language
  2. SI-8111

uncaught exception during compilation: "Could not find proxy for ..."

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: Scala 2.10.3, Scala 2.10.4-RC1
    • Component/s: Compiler Backend
    • Labels:
      None
    • Environment:

      Mac OSX 10.9, JDK 1.7.0_45, SBT 0.13.1

      Description

      It seems as I have caught something like a bug in Scala compiler. It is thrown both in 2.10.3 and 2.10.4-RC1.

      Just try to compile attached file 'Monads.scala'.

      In my environment it throws:

      unhandled exception while transforming Monads.scala
      [error] uncaught exception during compilation: java.lang.IllegalArgumentException
      [trace] Stack trace suppressed: run last compile:compile for the full output.
      [error] (compile:compile) java.lang.IllegalArgumentException: Could not find proxy for ma: Object in List(value ma, method flatMap, class Monad$class, object Monads, package <empty>, package <root>) (currentOwner= method apply )

      Full stack trace is shown there:

      https://gist.github.com/sergey-scherbina/8208552

      Sorry, if it is something known already or my own mistake. Thanks.

      1. build.sbt
        0.0 kB
        Sergey Scherbina
      2. Monads.scala
        2 kB
        Sergey Scherbina

        Issue Links

          Activity

          Hide
          Jason Zaugg added a comment -

          Appears to have regressed in 2.10.0, specifically in SI-5720 / https://github.com/scala/scala/commit/aabe71f

          Show
          Jason Zaugg added a comment - Appears to have regressed in 2.10.0, specifically in SI-5720 / https://github.com/scala/scala/commit/aabe71f
          Hide
          Jason Zaugg added a comment -

          /cc @som-snytt

          Show
          Jason Zaugg added a comment - /cc @som-snytt
          Hide
          Jason Zaugg added a comment - - edited

          Minimized:

          trait T {
          
            def crashy(ma: Any) {
              // okay
              val f1 = (u: Unit) => ma
              foo(f1)()
          
              // okay
              foo((u: Unit) => ma)
          
              // okay
              foo((u: Unit) => ma)(())
          
              // crash
              foo((u: Unit) => ma)()
              ???
            }
          
            def foo(f: Any): Any => Any
          }
          
          Show
          Jason Zaugg added a comment - - edited Minimized: trait T { def crashy(ma: Any) { // okay val f1 = (u: Unit) => ma foo(f1)() // okay foo((u: Unit) => ma) // okay foo((u: Unit) => ma)(()) // crash foo((u: Unit) => ma)() ??? } def foo(f: Any): Any => Any }
          Hide
          Jason Zaugg added a comment - - edited

          The problem is that the compiler first tries named/default arguments to correct the arity mismatch in:

          foo((u: Unit) => ma).apply()
          

          We need one argument, but an empty argument list is provided.

          This doesn't pan out, and it then falls back to autotupling which reinterprets the empty argument list as a `Tuple0`, better know as `()`.

          But, the names/default transform leaves a trace on the tree by way of the side-effect of changing the owner of the symbol representing the closure to the symbol of a temporary val `qual$1` emitted in the transform:

          {
            val qual$1: Any => Any @uncheckedBounds = T.this.foo(((u: Any) => ma));
            qual$1.apply
          }
          

          That temporary val is part of the rigmarole needed to maintain the correct evaluation order in `first.foo(x = second, y = third)`.

          We should restructure the `tryNamesDefaults` to avoid the destructive `changeOwner` until we're sure that the names/defaults approach will work out.

          I'm sure that we've got another instance of this bug reported, but I can't find it right now.

          Show
          Jason Zaugg added a comment - - edited The problem is that the compiler first tries named/default arguments to correct the arity mismatch in: foo((u: Unit) => ma).apply() We need one argument, but an empty argument list is provided. This doesn't pan out, and it then falls back to autotupling which reinterprets the empty argument list as a `Tuple0`, better know as `()`. But, the names/default transform leaves a trace on the tree by way of the side-effect of changing the owner of the symbol representing the closure to the symbol of a temporary val `qual$1` emitted in the transform: { val qual$1: Any => Any @uncheckedBounds = T.this.foo(((u: Any) => ma)); qual$1.apply } That temporary val is part of the rigmarole needed to maintain the correct evaluation order in `first.foo(x = second, y = third)`. We should restructure the `tryNamesDefaults` to avoid the destructive `changeOwner` until we're sure that the names/defaults approach will work out. I'm sure that we've got another instance of this bug reported, but I can't find it right now.
          Hide
          A. P. Marki added a comment -

          I don't know why you guys let total noobs go around making random one-line changes.

          Show
          A. P. Marki added a comment - I don't know why you guys let total noobs go around making random one-line changes.
          Show
          Jason Zaugg added a comment - https://github.com/scala/scala/pull/3328
          Hide
          Adriaan Moors added a comment -

          will be fixed by merging 2.10.x into master

          Show
          Adriaan Moors added a comment - will be fixed by merging 2.10.x into master

            People

            • Assignee:
              Jason Zaugg
              Reporter:
              Sergey Scherbina
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development