Imported From: https://issues.scala-lang.org/browse/SI-3174?orig=1
Reporter: @JamesIry
See #5211

@JamesIry said:
Ah, this appears to be a REPL problem.

$$ /usr/lib/scala-2.8.0.Beta1-prerelease/bin/scalac test.scala
$$ /usr/lib/scala-2.8.0.Beta1-prerelease/bin/scala Test
[Lscala.Enumeration$$Value;@7f5663a2

@JamesIry said:
Arg, I wish I could edit.

Previous comment should have been preceeded with modified code showing a wrapper object with main defined

$$ cat test.scala
object Test {
object Color extends Enumeration {
  val Blue = Value
  val Green = Value
}

class Board {
  val grid = Array(Color.Blue, Color.Green)
}

def main(args : Array[String]) {
   println((new Board).grid)
}
}

@lexspoon said:
Is this type error intended? Here is a smaller example showing the situation:

object test {
  def method() {
    class Foo extends AnyRef {
      object Color {
        object Blue
      }

      class Board {
        val grid = Color.Blue
      }
    }
    new Foo
  }
}

Where does a name escape its scope? Within the method, Color and Blue are in scope. Outside of the method, neither is visible. Where is the escape?

As a clue to what's happening, changing "new Foo" causes it to compile without error. Either deleting it or replacing it by "val x = new Foo" causes the type error to go away.

What seems to be happening is that Foo is temporarily inferred as the return type of the method's block. That's not desired, though, is it? The block should type check with an expected type of Unit. That means the last statement of the block should also type check with an expected type of Unit. Thus the type of new Foo should not ever make it out of the block's interior.

If anyone wants to defend this situation, then please also say what is different about this example, which does not trigger an error:

object test {
  def method() {
    class Foo extends AnyRef {
    }
    new Foo
  }
}

In this example, type Foo escapes its method in the same way as my first example, but now there is no type error. Why should there be an error about Foo's members but not about Foo itself?

If this needs to be fixed in the repl it can be. However, can the type checker's check for escaping values be made less aggressive? In this case it is raising a false alarm.

@odersky said:
(In r22184) Fixed #3174. Review by spoon

@odersky said:
(In r22253) Closes #3174 and #3560. Review by moors.

@odersky said:
(In r22254) Applied patch that closes #3560 and still fixes #3174.