You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Place the cursor on the i in isA and send a textDocument/definition request.
The response returns the definition of unary_!, which is incorrect.
Place the cursor on the i in isB and send the same request.
The response correctly returns the definition of the isB function.
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
The text was updated successfully, but these errors were encountered:
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:
i
inisA
and send atextDocument/definition
request.unary_!
, which is incorrect.i
inisB
and send the same request.isB
function.i
inisC
and send the same request.unary_!
.Environment
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
, orisC
) 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
The text was updated successfully, but these errors were encountered: