Closed arkdro closed 1 year ago
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.
Something strange is going on.
I've created a small project using nimble init. There are only 2 files. First file,
src/test.nim
:Second file,
src/aaa/amod.nim
:To reproduce:
bbb
. The status line containsamod.bbb proc (): int{.noSideEffects, gcsafe.}
M-.
to go to the definition ofbbb
in the second fileM-,
to return to the first fileisMainModule
isMainModule
is shown in the status line (it'sbool
)bbb
test.bbb: Error Type
The system:
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.