Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: Scala 2.10.0, Scala 2.11.0
    • Fix Version/s: Scala 2.12.0
    • Component/s: Reflection
    • Labels:
      None

      Description

      import scala.reflect.runtime.universe._
      import scala.reflect.runtime.{currentMirror => cm}
      import scala.tools.reflect.ToolBox
      
      object Test extends App {
        val tb = cm.mkToolBox()
        val expr = tb.parse("math.sqrt(4.0)")
        println(tb.eval(expr))
      }
      
      C:\Projects\Kepler\sandbox @ ticket/5943>myke run .
      scala.tools.reflect.ToolBoxError: reflective compilation has failed:
      
      object sqrt is not a member of package math
              at scala.tools.reflect.ToolBoxFactory$ToolBoxImpl$ToolBoxGlobal.throwIfErrors(ToolBoxFactory.scala:294)
              at scala.tools.reflect.ToolBoxFactory$ToolBoxImpl$ToolBoxGlobal.compile(ToolBoxFactory.scala:227)
              at scala.tools.reflect.ToolBoxFactory$ToolBoxImpl.compile(ToolBoxFactory.scala:391)
              at scala.tools.reflect.ToolBoxFactory$ToolBoxImpl.eval(ToolBoxFactory.scala:394)
              at Test$delayedInit$body.apply(t5943b2.scala:8)
              at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
              at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
              at scala.App$$anonfun$main$1.apply(App.scala:61)
              at scala.App$$anonfun$main$1.apply(App.scala:61)
              at scala.collection.immutable.List.foreach(List.scala:309)
              at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:32)
              at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:45)
              at scala.App$class.main(App.scala:61)
              at Test$.main(t5943b2.scala:5)
              at Test.main(t5943b2.scala)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              at java.lang.reflect.Method.invoke(Method.java:597)
              at scala.tools.nsc.util.ScalaClassLoader$$anonfun$run$1.apply(ScalaClassLoader.scala:71)
              at scala.tools.nsc.util.ScalaClassLoader$class.asContext(ScalaClassLoader.scala:31)
              at scala.tools.nsc.util.ScalaClassLoader$URLClassLoader.asContext(ScalaClassLoader.scala:139)
              at scala.tools.nsc.util.ScalaClassLoader$class.run(ScalaClassLoader.scala:71)
              at scala.tools.nsc.util.ScalaClassLoader$URLClassLoader.run(ScalaClassLoader.scala:139)
              at scala.tools.nsc.CommonRunner$class.run(ObjectRunner.scala:28)
              at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:45)
              at scala.tools.nsc.CommonRunner$class.runAndCatch(ObjectRunner.scala:35)
              at scala.tools.nsc.ObjectRunner$.runAndCatch(ObjectRunner.scala:45)
              at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:74)
              at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:96)
              at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:105)
              at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
      

        Issue Links

          Activity

          Hide
          Eugene Burmako added a comment - - edited

          When Jason and I were triaging reflection bugs today, we came to the conclusion that this one is a blocker for using toolboxes seriously, e.g. as a replacement for scala.tools.nsc.interactive. Well, it indeed is, because relative imports are very common in Scala programs.

          As to the comment itself, a possible solution would be to distinguish URLClassLoaders, which can exhaustively enumerate their contents, and treat them specially in the reflective compiler. That would bring conceptual feature parity to toolboxes w.r.t the regular compiler in 99% of the use cases.

          Show
          Eugene Burmako added a comment - - edited When Jason and I were triaging reflection bugs today, we came to the conclusion that this one is a blocker for using toolboxes seriously, e.g. as a replacement for scala.tools.nsc.interactive. Well, it indeed is, because relative imports are very common in Scala programs. As to the comment itself, a possible solution would be to distinguish URLClassLoaders, which can exhaustively enumerate their contents, and treat them specially in the reflective compiler. That would bring conceptual feature parity to toolboxes w.r.t the regular compiler in 99% of the use cases.
          Hide
          Grzegorz Kossakowski added a comment -

          Will that work with sbt, ide and Maven?

          Let's start with sbt and IDE.

          I don't know how sbt is handling classloaders so I added Mark to watchers and let him comment on that. Same for Iulian.

          Show
          Grzegorz Kossakowski added a comment - Will that work with sbt, ide and Maven? Let's start with sbt and IDE. I don't know how sbt is handling classloaders so I added Mark to watchers and let him comment on that. Same for Iulian.
          Hide
          Jason Zaugg added a comment -

          The IDE doesn't call ToolBox compilers. SBT already has a means to communicate the classpath to the embedded interpreter, see "Use the Scala REPL from project code¶ http://www.scala-sbt.org/release/docs/Howto/scala.html.

          But it is likely that some environments (maybe OSGi) will be fundamentally incompatible with classpath enumeration, and will not support ToolBox compilation. We might have to live with that (or provide hooks for someone else to build a bridge). But we shouldn't punish the mainstream.

          I believe that Paul's branch a few comments above has a little code for URLClassLoader enumeration.

          Show
          Jason Zaugg added a comment - The IDE doesn't call ToolBox compilers. SBT already has a means to communicate the classpath to the embedded interpreter, see "Use the Scala REPL from project code¶ http://www.scala-sbt.org/release/docs/Howto/scala.html . But it is likely that some environments (maybe OSGi) will be fundamentally incompatible with classpath enumeration, and will not support ToolBox compilation. We might have to live with that (or provide hooks for someone else to build a bridge). But we shouldn't punish the mainstream. I believe that Paul's branch a few comments above has a little code for URLClassLoader enumeration.
          Hide
          Grzegorz Kossakowski added a comment -

          The IDE might want to call it for features like conditional breakpoints where you want to compile a little piece of code, no?

          If we are designing API we should think about all future clients not only current ones.

          I agree that we should provide connivence for common case but we need to ensure that we have a way to support more exotic environments. In order to assure that, could we start with designing an API that allows one to pass classpath enumerator to Reflection API, try that with URLClassLoader-based enumerator and only then make it a default choice?

          Show
          Grzegorz Kossakowski added a comment - The IDE might want to call it for features like conditional breakpoints where you want to compile a little piece of code, no? If we are designing API we should think about all future clients not only current ones. I agree that we should provide connivence for common case but we need to ensure that we have a way to support more exotic environments. In order to assure that, could we start with designing an API that allows one to pass classpath enumerator to Reflection API, try that with URLClassLoader -based enumerator and only then make it a default choice?
          Hide
          Jason Zaugg added a comment -

          Yeah, that's what I meant by "provide hooks". We would just provide a standard implementation of that hook for URLClassLoader, SBT.

          Show
          Jason Zaugg added a comment - Yeah, that's what I meant by "provide hooks". We would just provide a standard implementation of that hook for URLClassLoader, SBT.

            People

            • Assignee:
              Eugene Burmako
              Reporter:
              Eugene Burmako
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development