Fix goto definition leading to case class for overloaded apply in another file

[MaciejG604]

Fixes #4769

[MaciejG604]

The current state of debugging this issue:

• the issue is present only in Scala 3
• there's a discrepancy between method symbol that we fetch from SemanticDB or PresentationCompiler and the state of GlobalSymbolIndex, SemanticDB/PR tells us that the symbol of the overloading apply is e.g. _empty_/Foo.apply(+1). and the GlobalSymbolIndex only contains the symbol _empty_/Foo.apply().
  The example project I work on looks like this:

// Main.scala
object Main {
  List(1).map(Foo.apply)
}

SemanticDB occurences of the Main.scala:

Occurrences:
[1:7..1:11) <= _empty_/Main.
[2:2..2:6) => scala/package.List.
[2:10..2:13) => scala/collection/immutable/List#map().
[2:14..2:17) => _empty_/Foo.
[2:18..2:23) => _empty_/Foo.apply(+1).

// Foo.scala
case class Foo(a: Int, b: Int)

object Foo {
  def apply(a: Int): Foo = new Foo(a, 2)
}

SemanticDB symbols (jsut the relevant part of them) of the Foo.scala:

Symbols:
_empty_/Foo.apply(). => method apply(a: Int, b: Int): Foo
_empty_/Foo.apply().(a) => param a: Int
_empty_/Foo.apply().(b) => param b: Int
_empty_/Foo.apply(+1). => method apply(a: Int): Foo
_empty_/Foo.apply(+1).(a) => param a: Int

Contents of the relevant bucket of GlobalSymbolIndex:

Notice that in the index there's no apply(+1) the one that is overloading the default case class apply has symbol apply().

[kpodsiad]

Hey @MaciejG604, I will just leave a couple of suggestions which may improve your work loop (they surely were a gamechanger to me!) I think that https://scalameta.org/metals/docs/contributors/getting-started should be a bit easier for newcomers to start, but in this comment I want to focus on that section. What works for me is:

• find places which interest me, that's where I'll put pprint.log(...) calls
• find unit test associated with given feature (you already found it)
• place .only after one test, should be relatively easy example. This will make sure that munit will run only only this test from the whole suite
• start sbt session and then within it run ~unit/testOnly test.DefinitionLspSuite

This will rerun this session after each saved change. Surely debugger is useful when one isn't familiar with codebase, but after some time I really liked pprint way ;)

---

Bonus:
In my ~/.sbt/1.0/build.sbt file I have

commands += Command.command("cls") { state =>
  print("\033c")
  state
}

then cls in sbt clear my console. I really like to use this like ~; cls; unit/testOnly test.DefinitionLspSuite

cc: @jkciesluk maybe you'll find this useful too!

[kpodsiad]

This shouldn't be necessary to make logging working, is it?

[kpodsiad]

You may find pprint.log more appealing rather than scribe