williamboman / nvim-lsp-installer

Further development has moved to https://github.com/williamboman/mason.nvim!
https://github.com/williamboman/mason.nvim
Apache License 2.0
2k stars 123 forks source link

Using the clangd provided by nvim-lsp-installer with --query-driver=<some toolchain> doesn't actually query the driver #511

Closed embeddedpenguin closed 2 years ago

embeddedpenguin commented 2 years ago

Problem description

If I use the clangd provided by lsp-installer, very specific command line arguments do not work.

The command is the following, but the only important parts are --query-driver=... and --compile-commands=...:

clangd --query-driver=/usr/bin/arm-none-eabi-gcc --compile-commands-dir=/storage/Shared/Projects/Embedded-Graphics-Learning/software/firmware/oracle_same54n19a/gcc --pch-storage=memory --background-index -j=4 --header-insertion-decorators=0 --log=verbose

For some reason clangd wasn't seeing the headers associated with my toolchain, so things like stdio.h, stdlib.h, etc.... were being red squiggled and marked as being not found. It didn't do this for me in emacs so I went to ~/.local/share/nvim/lsp_servers/clangd/clangd/bin/ and removed the clangd that was there and sure enough clangd could see my headers again. My guess is it has something to do with the binary clangd being downloaded. I have no way of testing this though. The clangd on my machine is the same version as the one being downloaded by the lsp server installer.

Here's when the clangd provided by lsp-installer was used, aka I didn't rename it to something so nvim wouldn't see it: image

Here's when the clangd on my machine was used rather than the one provided by lsp-installer: image

I realize there's not a lot going on in the second picture, but trust me it works now lol

I realize this may end up being difficult to reproduce, so if you need me to test some stuff let me know. I also don't know whose "fault" this is. It could be a permissions thing, or it could be the binary provided by llvm, or it could be nvim-lsp-config running things the wrong way. I have no idea.

Neovim version (>= 0.6)

NVIM v0.6.1 Build type: Gentoo LuaJIT 2.0.5

Operating system/version

Linux 5.15.16-gentoo-x86_64

I've recently downloaded the latest plugin version of both nvim-lsp-installer and nvim-lspconfig

Affected language servers

clangd

Steps to reproduce

  1. Open a project requiring you to specify --query-driver= in neovim
  2. try and specify --query-driver= with that project to the clangd provided by lsp-installer

Actual behavior

  1. Open a project requiring you to specify --query-driver= in neovim
  2. try and specify --query-driver= with that project to the clangd provided by lsp-installer
  3. toolchain headers won't be found

Expected behavior

  1. Open a project requiring you to specify --query-driver= in neovim
  2. try and specify --query-driver= with that project to the clangd provided by lsp-installer
  3. toolchain headers SHOULD be found

LspInfo

LspInfo:

 Language client log: /home/penguin/.cache/nvim/lsp.log
 Detected filetype:   c

 1 client(s) attached to this buffer: 

 Client: clangd (id: 1, pid: 26494, bufnr: [1])
    filetypes:       c, cpp, objc, objcpp
    autostart:       true
    root directory:  /storage/Shared/Projects/Embedded-Graphics-Learning/software/firmware/oracle_same54n19a
    cmd:             clangd --query-driver=/usr/bin/arm-none-eabi-gcc --compile-commands-dir=/storage/Shared/Projects/Embedded-Graphics-Learning/software/firmware/oracle_same54n19a/gcc --pch-storage=memory --background-index -j=4 --header-insertion-decorators=0 --log=verbose

 Configured servers list: jdtls, clangd, rust_analyzer, taplo, pyright

### Healthcheck

```shell
nvim-lsp-installer: require("nvim-lsp-installer.health").check()
========================================================================
## nvim-lsp-installer report
  - OK: neovim version >= 0.6.0
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - WARNING: **julia**: not available
  - OK: **bash**: `GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)`
  - OK: **tar**: `tar (GNU tar) 1.34`
  - OK: **gzip**: `gzip 1.11`
  - OK: **curl**: `curl 7.79.1 (x86_64-pc-linux-gnu) libcurl/7.79.1 OpenSSL/1.1.1m zlib/1.2.11 nghttp2/1.45.1`
  - OK: **wget**: `GNU Wget 1.21.2 built on linux-gnu.`
  - OK: **python3**: `Python 3.9.9`
  - OK: **node**: `v14.17.6`
  - OK: **Ruby**: `ruby 2.6.9p207 (2021-11-24 revision 67954) [x86_64-linux]`
  - OK: **Go**: `go version go1.17.7 linux/amd64`
  - OK: **sh**: `Ok`
  - OK: **RubyGem**: `3.1.6`
  - OK: **java**: `Ok`
  - OK: **npm**: `6.14.15`
  - OK: **javac**: `javac 11.0.14`
  - OK: **pip3**: `pip 21.3.1 from /usr/lib/python3.9/site-packages/pip (python 3.9)`

clangd version from my machine (WORKING):

clangd version 13.0.0
Features: linux
Platform: x86_64-pc-linux-gnu

clangd version from lsp-installer (NOT WORKING with --query-driver):

clangd version 13.0.0 (https://github.com/llvm/llvm-project d7b669b3a30345cfcdb2fde2af6f48aa4b94845d)
Features: linux+grpc
Platform: x86_64-unknown-linux-gnu
williamboman commented 2 years ago

Hello! Hmm I'm not too familiar with clangd. Have you read the this part and this part of their troubleshooting guide?

embeddedpenguin commented 2 years ago

Hello! Hmm I'm not too familiar with clangd. Have you read the this part and this part of their troubleshooting guide?

Yeah I've been through that a bunch of times. What I'm trying to say in this bug report is that the clangd binary that nvim-lsp-installer downloads and uses doesn't properly use the --query-driver=... argument I'm passing in. I know for a fact it's getting those arguments. It just isn't fetching the headers properly for some reason. This might just be the binary itself having a bug that is causing this. I don't know. I'm only reporting it here so that just in case other people face the same issue, they know why.

I've already confirmed that the clangd on my machine properly fetches the headers. The clangd nvim-lsp-installer provides does not fetch the headers properly.

embeddedpenguin commented 2 years ago

I've yet to find a reason this would be lsp-installers fault, so I'm going to close this and create an issue over at clang.