-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implicit conversion to function type produces incorrect symbol occurrence #1968
Comments
Thank you for reporting! This looks like a semanticdb-scalac bug. I played around with setting up a worksheet in the Metals test suite to reproduce, import scala.meta.interactive.InteractiveSemanticdb
val pc = InteractiveSemanticdb.newCompiler()
val x =
InteractiveSemanticdb
.toTextDocument(
pc,
"""
package a
object a {
implicit class RichInt(x: Int) {
def soRich(other: Int) = x + other
}
val op = 1
op soRich 2
}
""",
List("-P:semanticdb:synthetics:on", "-P:semanticdb:text:on")
)
scala.meta.internal.mtags.Semanticdbs
.printTextDocument(x)
pc.askShutdown() I see that method from akka-http has an advanced signature
The first step would be to reproduce in a minimized code example with no external dependencies and open an issue in scalameta/scalameta |
Closing this issue in favor of #1967 |
Realized I can transfer the issue. SemanticDB v4.3.0 object a {
implicit def addByNameNullaryApply(directive: Int): (=> Int) => Int = ???
def bar(fn: (=> Int) => Int): Int = 42
val get = 42
get {
42
}} Produces -- obtained
++ expected
- get/*_empty_.a.addByNameNullaryApply().*/
+ get/*_empty_.a.get.*/ Reported originally by @ckipp01 in https://github.com/scalameta/metals/issues/1052 A good place to start investigating this issue would be to write a test case in scalameta/tests/jvm/src/test/scala/scala/meta/tests/semanticdb/TargetedSuite.scala Line 181 in 44af455
Next, look at all the places where Line 53 in 44af455
|
Describe the bug
I've noticed this issue more lately where if I have for example the following small application...
I would expect that when I "goToDefinition" on
get
it would bring me to where it is defined. That's what it does in IntelliJ. However, in metals, it seems to bring me to the actual typeDefinition. For example, above it will end up leading me to theimplicit def addByNameNullaryApply(directive: Directive0)
in akka-land since indeedget
is a Directive0. However, I don't want to go to the type definition, but to the position whereget
is defined.I have a minimal project that illustrates this issue located here https://github.com/ckipp01/type-def-issue
To Reproduce
Steps to reproduce the behavior:
get
Expected behavior
Would jump to where
get
is defined.Installation:
Search terms
goToDefinition
The text was updated successfully, but these errors were encountered: