`Interactive.pathTo` contains `Literal(Constant(null))` as a head of path for incomplete program

area:ide

Compiler version

3.1.3-RC2 and later

Minimized code

See: https://github.com/tanishiking/dotty-interactive-playground/blob/50ea5babab3d6d124b98597873af371765b97bf3/src/main/scala/Main.scala#L45-L64

val sourceDefinition = "object Definition { def x    }"
val uriDefinition = new URI("file:///def")
driver.run(uriDefinition, sourceDefinition) // where driver: InteractiveDriver
given ctx: Context = driver.currentCtx

val pos = new SourcePosition(driver.openedFiles(uriDefinition), Spans.Span(sourceDefinition.indexOf("def x") + "def x".length))
val path = Interactive.pathTo(driver.openedTrees(uriDefinition), pos)
path.foreach(println)

Output

with 3.1.3-RC2 or later

Literal(Constant(null))
DefDef(x,List(),...)
Template(...)
TypeDef(...)

with 3.1.2

DefDef(x,List(),...)
Template(...)
TypeDef(...)

Expectation

Scala 3.1.3 should return the same result as Scala 3.1.2. There shouldn’t be a Literal(Constant(null)).

Additional context

This is a bit of a problem for Metals, for example, when Metals try to invoke advanced completion based on the path to the cursor position something like def | (| represents the cursor position). As a workaround Metals ignore Literas(Constant(null)). https://github.com/scalameta/metals/blob/92d8d9ecdaead1a6db2a9ebb1a85500c22c4714d/mtags/src/main/scala-3/scala/meta/internal/pc/completions/Completions.scala#L136-L139

[smarter]

this is what we did in our internal tooling that uses the compiler and it has been very handy!

Off-topic, but this is intriguing 😃, is this something you could share more information on?

More on-topic: I think it’s worth adding a comment to pathTo mentioning that it might return errorTermTree (but presumably only if ctx.reporter.errorsReported is true), and it seems like we could then close this issue.

[adampauls]

@tanishiking I think this is at least arguably working as intended? I recently made some changes (some of which @odersky largely rewrote) to add the errorTermTree in more places for incomplete parses. The motivation in those PRs (e.g. https://github.com/lampepfl/dotty/pull/14463) was to differentiate between e.g. foo(x,<EOF> and foo(x). Before the PR, these two had the same parse, but the PR changed it so that the former gives foo(x, Literal(Constant(null)).

I think Metals should expect to see the errorTermTree (Literal(Constant(null))) and ignore it? Note that I did not add errorTermTree, I just made it occur in more places. It’s possible some of my changes caused this particular change, but I’m not sure.