Skip to content
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

textDocument/definition incorrectly resolves the definition for names following unary_! #7063

Open
razeghi71 opened this issue Dec 24, 2024 · 0 comments

Comments

@razeghi71
Copy link

Describe the bug

Description

The textDocument/definition request behaves inconsistently when resolving the definition of names following the unary operator !

Steps to Reproduce

Here is the sample code where the issue occurs:

object Temp {
  def isA: Boolean = false

  def isB: Boolean = false

  def isC: Boolean = false

  def main(args: Array[String]): Unit = {
    println(!isA && !isB && !isC)
  }
}
  1. Place the cursor on the i in isA and send a textDocument/definition request.
    • The response returns the definition of unary_!, which is incorrect.
  2. Place the cursor on the i in isB and send the same request.
    • The response correctly returns the definition of the isB function.
  3. Place the cursor on the i in isC and send the same request.
    • The response again incorrectly returns the definition of unary_!.

Environment

  • Editor: Neovim
  • Validation: I validated this independently with the Metals server by using lsp4j.

Let me know if any further details are needed!

Expected behavior

Expected Behavior

The textDocument/definition request should consistently return the definition of the corresponding function (isA, isB, or isC) regardless of its position after a unary operator.

Operating system

macOS

Editor/Extension

Nvim (nvim-metals)

Version of Metals

v1.4.2

Extra context or search terms

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant