search

m-pilia / vim-ccls

Vim plugin for the ccls language server
MIT License
97 stars 7 forks source link

Calls tree is not expanded #24

Closed 0xb0b closed 4 years ago

0xb0b commented 4 years ago

Steps to reproduce

Environment

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui

health#LanguageClient#check                                                                          
========================================================================                             
   - OK: binary found: /home/xbob/.config/nvim/plugged/LanguageClient-neovim/bin/languageclient       
   - OK: languageclient 0.1.155                                                                   
   - OK: Floating window is supported and will be used for hover

## Python 3 provider (optional)                                                                      
   - INFO: Using: g:python3_host_prog = "/home/xbob/.env/python/neovim/bin/python"                    
   - INFO: Executable: /home/xbob/.env/python/neovim/bin/python                                       
   - INFO: Python version: 3.7.4                                                                         
   - INFO: pynvim version: 0.3.1 (outdated; from ~/.env/python/neovim/lib/python3.7/site-packages/neovim)
   - WARNING: Latest pynvim is NOT installed: 0.4.0
0xb0b commented 4 years ago

From the log, I can see that the request to the server is sent upon expansion. But there is no answer. Additional debug logs show the root cause. The filetype field in the provider dictionary is empty. The filetype is "cpp" when the CclsCallHierarchy initial call is made. However, &filetype becomes empty in handle_tree when the first response is handled. So all the subsequent requests fail. Apparently, as it is stated in the comment:

 " Send an LSP request. Mock a source file if necessary, since                                        
 " some LSP clients accept calls only from within a source file.

I do not know the reason why the filetype is empty in the handler. I could resolve the issue by adding the additional filetype parameter to handle_tree and passing filetype in ccls#messages#call_hierarchy. Then in handle_tree, it is saved in the dictionary instead of &filetype.

m-pilia commented 4 years ago

Hi @0xb0b, thanks for the detailed report and the analysis. I was able to reproduce the issue, and I think your conclusions are correct. The handler is vulnerable to timing issues.

You could please try #25 and check if it fixes the problem for you.

0xb0b commented 4 years ago

Yes, #25 resolves the problem. Thanks for the fix.