REPL not sufficiently isolated from class artifacts in current directory

Compiler version

3.0.0

Minimized code

➜  snips scala oq.scala
2
0
➜  snips
➜  snips scalac -version
Scala compiler version 3.0.0 -- Copyright 2002-2021, LAMP/EPFL
➜  snips rm *.class *.tasty
➜  snips scala oq.scala
2
2

Output

This should never happen:

➜  snips vi hi.scala
➜  snips cat hi.scala

@main def test() = println("hello, world")
➜  snips scala hi.scala
hello, world
➜  snips scalac hi.scala
➜  snips vi hi.scala
➜  snips scala hi.scala
hello, world
➜  snips cat hi.scala

@main def test() = println("goodbye, cruel world")
➜  snips

Expectation

Running a script or interactive REPL actually runs the source text.

This is a follow-up to https://github.com/lampepfl/dotty/issues/7635 which was improperly closed.

Noticed again at https://gitter.im/scala/scala?at=60a9b889850bfa2d3bdaae09

[SethTisue]

PR: #14021 (yes, that hypothesis was the way forward)

[SethTisue]

The King James Bible (1611) also spells it “subtil”. Most famously in Genesis: “the serpent was more subtil than any beast of the field…”

Dale and I spent about two hours looking at this today and we learned some things but don’t really have a solution in sight yet. But both of us want to keep working on it, both for the importance of the bug itself, and because it’s good learning and good saw-sharpening.

Some of the code we were studying:

• ReplCompiler#newRun is where each new thing entered in the REPL gets access to the bindings established earlier in the session; a fold repeatedly calls importPreviousRun, which does ctx.fresh and .withRootImports(RootRef(() => requiredModuleRef(path)) :: Nil) where path is successively repl.rs$line$1, repl.rs$line$2, and so on. (The repl. part was added by Tom in #12607.)

• References to names are resolved in Typer by findRef which calls findRefRecur which calls checkNewOrShadowed, which seems relevant and perhaps if we studied it (and/or added logging and/or stepped through it in a debugger) we’d have an aha moment.

At the broadest level, we still don’t know:

• Does something go wrong at the time the directory in the file system is seen and a package symbol created for it?
• Or does something first go wrong at the point when the def or val is entered?
• Or is all of that working as intended, and the bug occurs only when you attempt to reference the def or val?

We sort of circled around between these three possibilities, dipping shallowly into each one, without committing yet to truly proving or disproving a particular one.

Dale has a WIP branch with some added logging (but those logs have yet to produce a smoking gun).