REPL breaks when importing from object before its definition

[Jasper-M]

Everything after import Foo._; object Foo fails, in at least Scala 2.10.6, 2.11.8, 2.11.11 and 2.12.2.

scala> :paste
// Entering paste mode (ctrl-D to finish)

import Foo._
object Foo

// Exiting paste mode, now interpreting.

import Foo._
defined object Foo

scala> 42
<console>:10: error: not found: value Foo
import Foo._
       ^

Or

scala> import Foo._; object Foo
import Foo._
defined object Foo

scala> 42
<console>:10: error: not found: value Foo
import Foo._
       ^

Only in raw paste mode does it work.

scala> :paste -raw
// Entering paste mode (ctrl-D to finish)

import Foo._
object Foo

// Exiting paste mode, now interpreting.


scala> 42
res0: Int = 42

[som-snytt]

That's because when it scans history backward for what to import, it will always add the explicit import Foo._, but it has already passed the definition from which it would normally generate an import some.wrapper.Foo.

Workaround:

scala> object X { def x = 42 } ; import X._
defined object X
import X._

scala> x
res0: Int = 42

[lihaoyi]

This appears to be fixed in Ammonite

lihaoyi concrete$ amm
Loading...
Welcome to the Ammonite Repl 1.0.0-RC6
(Scala 2.12.2 Java 1.8.0_112)
If you like Ammonite, please support our development at www.patreon.com/lihaoyi
@ import Foo._; object Foo
import Foo._;
defined object Foo
@ 42
res1: Int = 42

Ammonite handles imports totally differently from the normal REPL, so I'm not surprised it behaves differently here

[som-snytt]

I have a WIP for the nsc REPL; when picking imports, it looked at a flattened list of "member handlers" instead of looking at a request at a time. I think I was waiting on the big refactor before contributing? Also it would be useful to fix imports of implicits. Not sure if any of that belongs in the new tool API.

[som-snytt]

Name binding should be respected with respect to the snippet, perhaps:

scala> :pa
// Entering paste mode (ctrl-D to finish)

object X { def X = 42 }
import X._

// Exiting paste mode, now interpreting.

X should mean the object and not the def.

Currently, the statements are taken separately: the import is taken to satisfy the user reference, and the object is imported to satisfy the import's reference; they are generated at differing depths, and are ambiguous because the object is imported by name.