Open kpodsiad opened 2 years ago
Thanks for reporting. This might need a fix in scalameta :thinking:
It was fixed by implementing PcRenameProvider
for local symbols. @tgodzik do you think we can close?
That does improve the situation, however foo
is not local, so unfortunately this will not work :/
But we are renaming renameMe
inside method foo
, which is local
But we are renaming
renameMe
inside methodfoo
, which is local
Ach, sure, but if we move it outside it will stop working for example:
//> using scala "2.13.10"
//> using lib "org.typelevel::cats-core:2.7.0"
import cats.Monad
import cats.syntax.all._
class Renaming[F[_]: Monad] {
// doesn't work
val renameMe = Monad[F].pure(5)
def foo = {
for {
first <- Monad[F].pure(5)
second <- renameMe
} yield first + second
}
// works
def foo_2 = {
val renameMe = Option(2)
for {
first <- Option(5)
second <- renameMe
} yield first + second
}
}
I would keep this open since there is still something weird going on.
Oh right, I though the issue was connected to local#
symbols. For now the only solution I see is to collect occurrences from both presentation compiler and semantic db for rename and not fallback to PC only for local symbols
Most likely though this needs a fix in semanticdb unfortunately to work.
Describe the bug
renameMe
infoo
andfoo_2
Expected behavior
Renaming work for both cases.
I took a quick look at semanticDB and there is no occurrence for the usage of
<- renameMe
for typeF
.Operating system
macOS
Editor/Extension
VS Code
Version of Metals
0.11.7+59-4322516c-SNAPSHOT
Extra context or search terms
renaming refactor