Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
scabug opened this issue Jan 1, 2014 · 7 comments
Closed

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

scabug opened this issue Jan 1, 2014 · 7 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jan 1, 2014

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 , package ) (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.

@scabug
Copy link
Author

@scabug scabug commented Jan 1, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8111?orig=1
Reporter: Sergey Scherbina (sergey.scherbina)
Affected Versions: 2.10.3, 2.10.4-RC1
Other Milestones: 2.11.0-M8
See #5720
Attachments:

  • build.sbt (created on Jan 1, 2014 3:20:14 PM UTC, 28 bytes)
  • Monads.scala (created on Jan 1, 2014 3:20:14 PM UTC, 2400 bytes)

@scabug
Copy link
Author

@scabug scabug commented Jan 5, 2014

@retronym said:
Appears to have regressed in 2.10.0, specifically in #5720 / scala/scala@aabe71f

@scabug
Copy link
Author

@scabug scabug commented Jan 5, 2014

@retronym said:
/cc @som-snytt

@scabug
Copy link
Author

@scabug scabug commented Jan 5, 2014

@retronym said (edited on Jan 5, 2014 3:50:50 PM UTC):
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
}

@scabug
Copy link
Author

@scabug scabug commented Jan 5, 2014

@retronym said (edited on Jan 5, 2014 4:21:44 PM UTC):
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.

@scabug
Copy link
Author

@scabug scabug commented Jan 6, 2014

@scabug
Copy link
Author

@scabug scabug commented Jan 14, 2014

@adriaanm said:
will be fixed by merging 2.10.x into master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants