Open xrfez opened 2 years ago
I'm a little confused by the issue, I get that hover etc are not working, the part about scoop, paths, etc that was too just get things to compile, but still no joy with respect to nimsuggest. Did I understand correctly?
I don't have any windows machines and I haven't used it in forever. First thing we need to do is get you some more info as to what the extension is trying to do and what might be broken.
Here is the part of the readme that outline how to get a dev version up and running: https://github.com/saem/vscode-nim#developing-the-extension. It should be super quick, clone, npm install, open the folder in vscode, hit F5. The slowest part is likely the network downloads.
F5 will launch a debug version of the extension in a new vscode window, the vscode window that launched it will show debug output from said debug version in the debug console.
First I'd recommend opening a folder in the debug version to a hello world Nim project. Something super basic. In the debug console it'll show you paths like where it found nim, nimsuggest, etc.
Once you have the above base line, then open up your real project in the debug version. This will likely generate a ton of debug output but you can confirm the paths, see the indexing of files, etc. If there are errors encountered it'll output them there most likely.
It won't solve the issue necessarily, but I think it'll give some hints as to what to try next.
I should clarify. Both Go to Definition
and Hover
issues are resolved by moving to the mingw64
toolchain. Don't both of these depend on nimsuggest
? nimsuggest.exe
is now a running process where as before it wouldn't start at all with the extension or on the CL. Following #75 workaround for installing mingw64 to C:\
also resolved the issue no matter where nim
was installed. Therefore mingw64 is the missing/working dependency.
I believe it was my installed version of gcc (11.2.0) causing the grief because it was not the mingw64 gcc (12.1.0). While I could compile nim files and everything seemed to be working, I could not manually start nimsuggest
and experienced this bug. The pathing and scoop steps were just for reference if anyone else was looking for a solution.
I will re-create the bug and gather some more information following your detailed steps. Thank you.
@saem From the looks of it, its something to do with msys itself not being on the PATH via choosenim, but nimsuggest
is requiring it. Very very odd!
Perhaps it's a choosenim bug after all, with regards to how it sets it up? Or maybe its a nimsuggest bug?
I'm guessing it's a choosenim issue, the extension really doesn't do much special here.
I've done a little bit of experimenting, and it looks like nimsuggest just doesn't open properly through choosenim, even through the command line:
The code execution cannot proceed because libwinpthread-1.dll was not found. Reinstalling the program may fix this problem.
It would be nice if someone could check this on their Windows machine to make sure this problem isn't due to me messing up my PATH or something like that.
Checking the %errorlevel%
, it's the same one as you get in the developer console in VSCode (-1073741515
, or 0xC0000135
).
The DLL in question (libwinpthread-1.dll) doesn't get copied over to the ~/.nimble/bin
, but it is available in the ~/.choosenim/toolchains/mingw64/bin
, so maybe that's why adding that to the PATH fixes the problem. (It also makes nimsuggest
work in the command line.) Adding the nim bin folder wasn't necessary on my end.
This makes it seem likely that it's a choosenim issue with the nimsuggest
shim.
Great investigation.
I'm wondering do you think you could detect the issue and maybe output an error telling the user that their nimsuggest/choosenim might be busted?
I'm not familiar with the VSCode API, but where nimSuggestExec.execNimSuggest(..)
currently calls console.error(..)
, one of those red error popups should probably be created instead? (I think that's what window.showErrorMessage
does in this StackOverflow post.)
I just tried a fresh install of choosenim on a different machine and got the same command line error so I might go open an issue on the choosenim repo.
I have nimble (v2.0) and Archlinux nim package (v1.6). I had a syntax highlighting problem for default values on object fields (issue #129), because /usr/bin/nim (1.6 package) was being used. So I removed the Archlinux package and kept only local nimble installation. The syntax highlighting doesn't complain anymore (so I closed the issue), but I don't get no hover interaction, no goto definition. It seems that it's related to #97 (this one) and #102. If I show the developer console on vs code, I get:
If I run on bash:
$ nimsuggest --epc --v2 animation.nim
44233
However, the error persists.
Go to Definition and Hover Tips stopped working after updating nim (1.4.2 -> 1.6.6)
nim-Version: 1.6.6 vscode-Version: 1.67.2
The update initially broke functionality with the original nim extension: https://marketplace.visualstudio.com/items?itemName=kosz78.nim
I found this extension has the same issue. And I also found this extension!
I use scoop as my package manager therefore nim/gcc/python... are inside the scoop folder and individually in
PATH
.Trying all permutations of install/uninstall/re-order with vscode/Extension/Settings..nim/path and a clean install with choosenim, the workaround was identified in #75 where nim and mingw64 were installed to
"C:\nim"
and"C:\mingw64"
respectively and the"...\bin"
folders confirmed inPATH
.This is less than ideal... and after some testing it seems like my gcc version 11.2.0 is actually the issue.
The fix for me was:
Uninstall gcc with:
scoop uninstall gcc
Install MSYS2 with:scoop install msys2
Open MSYS2 in:scoop\apps\msys2\current
and runmsys2_shell
Update:pacman -Syuu
- May need to execute more than once. Install:pacman -S mingw-w64-x86_64-toolchain
- Install everything. AddC:\Users\%USERPROFILE%\scoop\apps\msys2\current\mingw64\bin
to PATH.