Go-to-definition for implicit apply only goes to apply

[harpocrates]

Describe the bug

Code:

trait Foo {
  def someNum
  def apply(i: Int): Unit = println(someNum)
}
object Bar extends Foo {
  def someNum = 42
}

object Test {
  Bar(2)
}

Cursor on Bar in Bar(2), go-to-definition goes to Foo.apply.

Expected behavior

Go-to definition should report two definitions:

• object Bar
• def apply on Foo

LSP is designed to accommodate multiple definitions.

Operating system

Windows

Editor/Extension

VS Code

Version of Metals

1.5.1

Extra context or search terms

No response

[harpocrates]

Looks like this used to work but regressed with #7028. The semantic DB path handles this, but not the PC one.

What is the thinking around keeping all of the various alternate codepaths? Should this sort of logic now be reimplemented using the PC?

[kasiaMarek]

What is the thinking around keeping all of the various alternate codepaths?

The idea is that in some conditions some of this strategies may fail, so we have multiple fallbacks. The one that should give the most accurate and up to date solution is used as the first one.

Should this sort of logic now be reimplemented using the PC?

Yeah, ideally behaviour of using semanticdb or pc in compiling code should be the same.

[harpocrates]

Ok, makes sense. I see you self assigned, but let me know if there's anything I can do to help here. I mostly didn't want to go blindly added a parallel code path, but maybe that is what we want in this case.

Long term, sounds like we want at least the preferred strategy to support all features, then the fallbacks can be less expressive.

[kasiaMarek]

I created a PR with a fix for Scala 2, this still needs to be removed similarly in Scala 3. (It leads only to the object and not apply).