PMunch / nimlsp

Language Server Protocol implementation for Nim

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

shows 'Error Type'

arkdro opened this issue · comments

Something strange is going on.

I've created a small project using nimble init. There are only 2 files.
First file, src/test.nim:

import aaa/amod

when isMainModule:
  var x = bbb()
  echo("Hello, World!", x)

Second file, src/aaa/amod.nim:

proc bbb *(): int =
  1

To reproduce:

  1. open the first file in emacs (lsp activates)
  2. position the cursor on bbb. The status line contains amod.bbb proc (): int{.noSideEffects, gcsafe.}
  3. press M-. to go to the definition of bbb in the second file
  4. press M-, to return to the first file
  5. press up arrow to move the cursor to isMainModule
  6. wait a little till the type of isMainModule is shown in the status line (it's bool)
  7. press down arrow to move the cursor to bbb
  8. the status line contains test.bbb: Error Type

The system:

  • debian 11.5
  • fresh user
  • emacs 27.1 (nim-mode and lsp-mode installed from the fresh output of 'list-packages'. Added a nim-mode-hook to activate lsp)
  • choosenim v0.8.4 (downloaded manually)
  • nim 2.0.0 (installed using choosenim)

The similar problem happened on other system, where nim 2.0.0 is installed using manual tarball download. On that system LSP crashes and emacs suggest to restart it. The crash happens all the times after opening the file for the first time. After the restart the LSP works better - almost no crashes on jumping back and forth in sources.

If NimLSP is built after the 2.0 version was installed I believe this is a nimsuggest bug. If not then rebuild NimLSP for Nim 2.0 and try again. If you enable debug logging for NimLSP durfng the build it will log the corresponding nimsuggest commands to run in order to perform the same actions. Could you run these in nimsuggest and check if the error persists?

I've rebuilt the lsp, then looked into the lsp debug log and tried to send the similar commands manually to nimsuggest.
This is what I got:
after nimsuggest breaks and starts reply with 'Error Type', I send a query for some unreasonable location (e.g. line 100, while the file only has 5 lines). Nimsuggest returns an empty response. Then I query it for the problematic place and it replies with the correct info.

user@dev:/tmp/test$ nimsuggest --find test.nim
usage: sug|con|def|use|dus|chk|mod|highlight|outline|known|project file.nim[;dirtyfile.nim]:line:col
type 'quit' to quit
type 'debug' to toggle debug mode on/off
type 'terse' to toggle terse mode on/off
> def test.nim:4:6
def     skVar   test.x  int     /tmp/test/test.nim      4       6       ""      100

> def test.nim:3:6
def     skConst system.isMainModule     bool    /user/.choosenim/toolchains/nim-2.0.0/lib/system/compilation.nim     24      2       "True only when accessed in the main module. This works thanks to\x0Acompiler magic. It is useful to embed testing code in a module."  100

> def test.nim:4:11
def     skProc  amod.bbb        proc (): int{.noSideEffect, gcsafe.}    /tmp/test/aaa/amod.nim 1
        5       ""      100

> def aaa/amod.nim:1:6
def     skProc  amod.bbb                /tmp/test/aaa/amod.nim  1       5       ""      100

> def test.nim:4:11
def     skUnknown       test.bbb        Error Type      /tmp/test/test.nim      4       10     ""       100

> def test.nim:4:11
def     skUnknown       test.bbb        Error Type      /tmp/test/test.nim      4       10     ""       100

> def test.nim:3:6
def     skConst system.isMainModule     bool    /user/.choosenim/toolchains/nim-2.0.0/lib/system/compilation.nim     24      2       "True only when accessed in the main module. This works thanks to\x0Acompiler magic. It is useful to embed testing code in a module."  100

> def aaa/amod.nim:1:6
def     skProc  amod.bbb                /tmp/test/aaa/amod.nim  1       5       ""      100

> def aaa/amod.nim:2:2

> def aaa/amod.nim:2:3

> def test.nim:4:11
def     skProc  amod.bbb        proc (): int{.noSideEffect, gcsafe.}    /tmp/test/aaa/amod.nim 1
        5       ""      100

> def test.nim:3:6
def     skConst system.isMainModule     bool    /user/.choosenim/toolchains/nim-2.0.0/lib/system/compilation.nim     24      2       "True only when accessed in the main module. This works thanks to\x0Acompiler magic. It is useful to embed testing code in a module."  100

> def test.nim:4:11
def     skProc  amod.bbb        proc (): int{.noSideEffect, gcsafe.}    /tmp/test/aaa/amod.nim 1
        5       ""      100

> def aaa/amod.nim:1:6
def     skProc  amod.bbb                /tmp/test/aaa/amod.nim  1       5       ""      100

> def test.nim:3:6
def     skConst system.isMainModule     bool    /user/.choosenim/toolchains/nim-2.0.0/lib/system/compilation.nim     24      2       "True only when accessed in the main module. This works thanks to\x0Acompiler magic. It is useful to embed testing code in a module."  100

> def test.nim:4:11
def     skUnknown       test.bbb        Error Type      /tmp/test/test.nim      4       10     ""       100

> def aaa/amod.nim:100:100

> def test.nim:4:11
def     skProc  amod.bbb        proc (): int{.noSideEffect, gcsafe.}    /tmp/test/aaa/amod.nim 1
        5       ""      100

>

Since the error appears in Nimsuggest you should raise this issue in the Nimsuggest repo. There's not much NimLSP can do to fix this kind of upstream bugs. Thanks for reporting, and it would be great if you could link to this issue when you create it on the Nimsuggest side.