Unresponsive when open C/C++ files

[THZrry]

This my computer,
Windows 11 23h2, winlibs-MinGW11.2.0

C:\Users\XX>gcc --version
gcc (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When I use ecode to open C/C++ files, it will be unresponsive.
When I remove clangd from lspclient.json, I can open C/C++ files without unresponsities.

So is it wrong when connecting with clangd? In other environments, I haven't meet this yet, so it's about my local environment. Clangd is installed locally, though this:

C:\Users\XX>clangd --version
(built by Brecht Sanders) clangd version 12.0.1

C:\Users\XX>where clangd
C:\Program Files\MinGW64\bin\clangd.exe

[ghost]

If you have no real need to use the GNU toolchain, use this instead:

https://github.com/mstorsjo/llvm-mingw/releases

[THZrry]

But mine is llvm too

C:\Users\XX>where gcc
C:\Program Files\MinGW64\bin\gcc.exe
C:\Users\XX>cd C:\Program Files\MinGW64\bin
C:\Program Files\MinGW64\bin>dir
 C:\Program Files\MinGW64\bin 的目录

2024/03/19  01:20    <DIR>          .
2021/07/29  03:15    <DIR>          ..
... ...
2021/07/29  03:15           759,310 libLLVMAArch64AsmParser.dll
2021/07/29  03:15         3,612,686 libLLVMAArch64CodeGen.dll
2021/07/29  03:15         1,547,790 libLLVMAArch64Desc.dll
2021/07/29  03:15           249,870 libLLVMAArch64Disassembler.dll
2021/07/29  03:15            18,958 libLLVMAArch64Info.dll
2021/07/29  03:15           136,718 libLLVMAArch64Utils.dll
2021/07/29  03:15            62,990 libLLVMAggressiveInstCombine.dll
2021/07/29  03:15         1,991,182 libLLVMAMDGPUAsmParser.dll
2021/07/29  03:15         5,374,990 libLLVMAMDGPUCodeGen.dll
2021/07/29  03:15         2,862,094 libLLVMAMDGPUDesc.dll
2021/07/29  03:15           329,742 libLLVMAMDGPUDisassembler.dll
2021/07/29  03:15            17,422 libLLVMAMDGPUInfo.dll
2021/07/29  03:15           418,830 libLLVMAMDGPUUtils.dll
2021/07/29  03:15         2,977,806 libLLVMAnalysis.dll
2021/07/29  03:15           533,006 libLLVMARMAsmParser.dll
2021/07/29  03:15         2,962,958 libLLVMARMCodeGen.dll
2021/07/29  03:15         1,064,974 libLLVMARMDesc.dll
2021/07/29  03:15           307,726 libLLVMARMDisassembler.dll
2021/07/29  03:15            18,958 libLLVMARMInfo.dll
2021/07/29  03:15            25,102 libLLVMARMUtils.dll
2021/07/29  03:15           379,406 libLLVMAsmParser.dll
2021/07/29  03:15           761,358 libLLVMAsmPrinter.dll
2021/07/29  03:15           147,982 libLLVMBinaryFormat.dll
2021/07/29  03:15           382,990 libLLVMBitReader.dll
2021/07/29  03:15            67,598 libLLVMBitstreamReader.dll
2021/07/29  03:15           196,110 libLLVMBitWriter.dll
2021/07/29  03:15            29,198 libLLVMCFGuard.dll
2021/07/29  03:15         4,023,822 libLLVMCodeGen.dll
2021/07/29  03:15         2,677,262 libLLVMCore.dll
2021/07/29  03:15           214,030 libLLVMCoroutines.dll
2021/07/29  03:15           176,654 libLLVMCoverage.dll
... ...
2021/07/29  03:15           711,694 yasm.exe
2021/07/29  03:15           705,550 ytasm.exe
2021/07/28  22:59           139,790 zlib1.dll
             395 个文件    353,017,659 字节
               2 个目录  4,593,283,072 可用字节

C:\Program Files\MinGW64\bin>

[ghost]

But mine is llvm too

You are using a very old version of winlibs.com's MinGW distro. The latest is already GCC 13.2.0 and LLVM 17.0.6! Nevertheless, the LLVM version of winlibs.com's MinGW distro is only a second thought. It's not first class support like llvm-mingw. It's only an extension to the GNU toolchain and it uses the GNU toolchain's headers and libraries. You can verify that it links with libstdc++, not libc++. Clangd is not optimized to work with such a config. Yes, it should work in theory. But I don't think it will work optimally.

[ghost]

Another thing I want to remind you of is: don't put things that are not installed by an installer (with admin privileges) into C:\Program Files. This is a bad practice. It will cause very obscure issues with permissions, even if you are using the admin account. Second to that, don't put the MinGW distro in a directory with spaces in its name. The most optimal location is at the root of the drive. You usually see the MinGW distro in C:\ or D:\ in internet tutorials, don't you? C:\mingw64 or D:\Work\mingw64 will work. But remember to not put the mingw64 directory too deep in nested directories. This will cause problems, too.

[ghost]

Btw, if you can build ecode from source using the latest code from Github, please test with that version, too. The developer has fixed a bug with the LSP client: #157 (comment)

[THZrry]

I remember I seem to modify the program files dir. But this does not matter, so is it said ecode is not planed to support this old version of clangd? Will ecode pass unsupported lsp servers in some future versions?

[THZrry]

Yes, I tried to build, but maybe it's my environment's fault, I failed build though

PS C:\Users\XX\Desktop\temp\eepp> lua premake5.lua --windows-mingw
C:\cmdline\lua.exe: premake5.lua:1: attempt to call a nil value (global 'newoption')
stack traceback:
        premake5.lua:1: in main chunk
        [C]: in ?

My lua is lua5.4.6 built from source (it's only one exe...)
besides, there's another lua within xmake, without any surprises it fails too.
haha, this is definitely my fault to make my environment a mass

[ghost]

Yes, I tried to build, but maybe it's my environment's fault, I failed build though

PS C:\Users\XX\Desktop\temp\eepp> lua premake5.lua --windows-mingw
C:\cmdline\lua.exe: premake5.lua:1: attempt to call a nil value (global 'newoption')
stack traceback:
        premake5.lua:1: in main chunk
        [C]: in ?

My lua is lua5.4.6 built from source (it's only one exe...) besides, there's another lua within xmake, without any surprises it fails too. haha, this is definitely my fault to make my environment a mass

Even though the build script for premake5 is a Lua file, it will not work with a regular Lua interpreter. You will need to download premake5.exe from their website. You can think of it as a special Lua interpreter.

Btw, it's very likely that you will need MSYS2 as your Powershell will not work: premake/premake-core#2196. If you use MSYS2 then you don't need to download premake5 from their website as MSYS2 has packages for premake5.

[ghost]

I remember I seem to modify the program files dir. But this does not matter, so is it said ecode is not planed to support this old version of clangd? Will ecode pass unsupported lsp servers in some future versions?

I never said ecode requires a specific version of clangd. I'm only trying to help, and I guess one of the potential problem is your version of clangd failed to do its job.

[THZrry]

Oh, it's my ignoring. I don't know premake before. I will try later.

[THZrry]

It's seem that xmake is similar to premake in some ways...

[SpartanJ]

It's seem that xmake is similar to premake in some ways...

xmake is similar in some aspects but they're very different build systems and not compatible with each other.

If you want to build ecode you can follow the updated steps here. If you want to avoid building the other eepp projects you can add ecode at the end of the make command, like: mingw32-make.exe -C make\windows config=release_x86_64 ecode.

As iahung2 mentioned, there was a related fix that could help with you issue that's currently not in any released ecode version. I'll build it myself in a few days if you're unable to build it. But I'm not completely sure that this will help. I've never experienced any unresponsiveness from the LSP, but the only way to be unresponsive is that the communication thread is locking the main/GUI thread, there are a couple of small locks that could affect it but they're usually very short-lived (for example updating the semantic syntax highlighting while rendering). I don't think that your particular clangd installation should affect the final result, since LSP communication is always async to avoid any possible unresponsiveness, so if something it's slow it should be fixed in ecode. Also if possible could you describe or show us how the unresponsiveness happens? This could be very helpful to locate the issue. What I'm almost sure this is a Windows specific issue, so for the moment I'll tag it as a windows specific bug.

superchick please let's try to keep issues conversations centered on the issues, I don't want to focus attention on topics that are not related to the project, it's not helpful.

[THZrry]

As iahung2 mentioned, there was a related fix that could help with you issue that's currently not in any released ecode version. I'll build it myself in a few days if you're unable to build it. But I'm not completely sure that this will help. I've never experienced any unresponsiveness from the LSP, but the only way to be unresponsive is that the communication thread is locking the main/GUI thread, there are a couple of small locks that could affect it but they're usually very short-lived (for example updating the semantic syntax highlighting while rendering). I don't think that your particular clangd installation should affect the final result, since LSP communication is always async to avoid any possible unresponsiveness, so if something it's slow it should be fixed in ecode. Also if possible could you describe or show us how the unresponsiveness happens? This could be very helpful to locate the issue. What I'm almost sure this is a Windows specific issue, so for the moment I'll tag it as a windows specific bug.

OK, like this:

res.mp4

There's about 0.2s responding before it turns unresponsive (does it matter?)...

[SpartanJ]

Ohh, I see! Then this is probably the same issue as #129 . Most probable cause is that clangd is hanging and ecode hangs as consequence. See this comment. I'll send you a build to test soon.

[ghost]

@THZrry Try moving hello_world.c outside of OneDrive to see if it helps. If it doesn't help, try moving the ecode directory outside of OneDrive, too.

[THZrry]

No, in fact, both the two are in my disk (see Bowpad's title)
But I really installed rust with GNU toolchain before.

[ghost]

Note: The OP is not opening hello_world.c the normal way. They dragged it into ecode. Please try to open the file with Open File button in ecode. Btw, I always think it's your version of clangd that is causing the problem. Could you test with the clangd from llvm-mingw?

[THZrry]

Ummm, I try as you say too, and now there're four known methods to open: dragging, cmdline args, open file dialog and open a folder with the C/CPP file. The results are still unresponsiveness. I think it's no doubt that the cause is clangd or other LSP servers.

Moreover, I opened a rust file (in a tauri project) and it turns unresponsive too.

Btw, I always think it's your version of clangd that is causing the problem. Could you test with the clangd from llvm-mingw?

I will have a try on llvm-mingw later.

[THZrry]

Ok, I tried.
This works any way. Maybe you are right. But rust files cannot open still, though my rust is the newset version. Strange...
(So why llvm-mingw's gcc is only a link of clang...)

[SpartanJ]

Sorry guys I'm a little lost.

 This works any way.

What do you mean with this?

 Moreover, I opened a rust file (in a tauri project) and it turns unresponsive too.

Any unresponsive LSP will turn into an unresponsive ecode without the #129 fix. BTW maybe you can run ecode with -ldebug command line argument and send me the logs (here you can read how to get them). This is usually really helpful since I can read the LSP errors.

[THZrry]

I think I know why it fails now.
It's because the missing cmdling arg: limit-references
ecode_llvmmingw.log
ecode_winlibsmingw.log
So @iahung2 is correct, the version of clangd is not compatible.

[SpartanJ]

Yes, clangd is too old, I can remove that parameter for the default LSP configuration though. I need to check the minimum version that supports each of the parameters we are using by default and decide which version we will support as a minimum version. clangd improved drastically with each version, so supporting very old versions also doesn't make much sense.

As for the rust issue, you installation is incorrect the important error is here:
error: Unknown binary 'rust-analyzer.exe' in official toolchain 'stable-x86_64-pc-windows-gnu'.. Please read #129 because it's the exact same issue. What I fixed there is to gracefully manage an invalid LSP installation or configuration.

[SpartanJ]

I can confirm this issue is a duplicate of #129 and that it's already fixed in dev.
A preview build of 0.5.2 can be tested here: ecode-windows-0.5.2-preview-x86_64.zip

[THZrry]

Awsome! It works!
Now this version of clangd is compatible with ecode, so do rust.

[THZrry]

clangd improved drastically with each version, so supporting very old versions also doesn't make much sense.

BTW how will you do if the version is really too old? Disable it?

[SpartanJ]

Awesome!
I think I'll add a generic notification to notice the user that the LSP failed to initialize, and if possible add some error information. Since LSP initialization can fail for an unknown number of reasons (not only an old version).