bugfix: in semanticdb make synthetic apply disambiguator consistent w/ Scala 2 implicit

[kasiaMarek]

Previously:
For the following code:

case class Foo(a: Int, b: Int)

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

In SemanticDB the synthetic apply in Scala 3 would get () disambiguator:

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

where, in Scala 2 implementation the synthetic apply gets (+1) disambiguator:

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

Now:
We make sure that for overloaded methods synthetic ones are added at the end to fix the incompatibility w/ Scala 2 implementation.

connected to: scalameta/metals#4769

[anatoliykmetyuk]

You can use partition instead of sort to make it linear.

[bishabosha]

awesome, thanks a lot! sorry for the delay

[filipwiech]

Hello @kasiaMarek, gentle ping. 😉 Is there anything left to do here? Would be great to get this in time for 3.3.2 if possible (no pressure of course). 🙂

[bishabosha]

needs a rebase, otherwise I'm not sure why it didn't automerge before.

Edit: im doing the rebase, there was probably another semanticdb change that was merged at the same time as the CI was running and caused the conflict

[kasiaMarek]

@bishabosha, tests failed, though it doesn't seem connected to the fix

[bishabosha]

Thanks, I restarted the CI because as you say it looked like some unrelated network error

[tgodzik]

@Kordyjan was this backported or will be added in 3.3.3 ?

[tgodzik]

Ach nvm. I see it's in the queue