Rust-analyzer in neovim seems to fail with error in log: "Failed to run build scripts ... no current exe available"

editors and IDEs
1

I am trying to follow the neovim manual to set up LSP (":h lsp"), but things do not seem to be working and I'm at a loss. I get these errors in the log file (more if I increase the output verbosity, but...):

[START][2024-02-15 14:58:27] LSP logging initiated
[WARN][2024-02-15 14:58:27] .../lua/vim/lsp.lua:1637 "buf_attach_client called on unloaded buffer (id: 1): "
[ERROR][2024-02-15 14:58:32] .../vim/lsp/rpc.lua:734 "rpc" "rust-analyzer" "stderr" "[ERROR rust_analyzer::main_loop] FetchBuildDataError:\nFailed to run build scripts for /home/lacall/proj/om/core: no current exe available (short)\n\n"
[ERROR][2024-02-15 14:58:33] .../vim/lsp/rpc.lua:734 "rpc" "rust-analyzer" "stderr" '[ERROR rust_analyzer::lsp_utils] overly long loop turn took 196.369724ms (event handling took 115.232941ms): AddDiagnostic { id: 0, workspace_root: AbsPathBuf("/home/lacall/proj/om/core"), diagnostic_code: Some("unused_imports") }\n'

Also ":lua =vim.lsp.buf.server_ready()" reports "false", though something is allowing neovim to report for the opened .rs file several instances of "_ multiple associated items are never used". And ":verbose set omnifunc?" yields only "omnifunc=".

cargo check runs successfully in this project, and I have run cargo build --release, so there are exes available for rust-analyzer and this project itself, anyway. The error seems to still occur after running "cargo clean".

rust-analyzer is built from commit 424da1007 (Sun Jul 16 00:50:43 2023)because OpenBSD 7.4 stable only provides rustc 1.72.1, and later versions of rust-analyzer don't seem to build without errors from the compiler.

I can provide my init.lua or other info if that would help.

Thanks much!!

1 Like
2

Here is my init.lua file (with many comments removed; I'm experimenting with some examples of using plugins):

vim.cmd("set completeopt=menu,preview,noselect,noinsert") --,menuone
--why doesnt next line work? Doing command didn't either: ":map <C-^>".
vim.keymap.set('n', '', 'C-^', { desc = 'Edit the alternate file' })

--per Lsp - Neovim docs
vim.lsp.start({
name = 'r-a-per-.config-nvim-init.lua',
cmd = {'rust-analyzer'},
root_dir = vim.fs.dirname(vim.fs.find({'Cargo.toml'}, { upward = true })[1]),
})

vim.g.mapleader = ' '
vim.g.maplocalleader = ' '
vim.o.hlsearch = false
vim.wo.number = true
vim.o.mouse = 'a'
vim.o.termguicolors = true

-- [[ Basic Keymaps ]]

-- Keymaps for better default experience
-- See :help vim.keymap.set()
vim.keymap.set({ 'n', 'v' }, '', '', { silent = true })

-- Remap for dealing with word wrap
vim.keymap.set('n', 'k', "v:count == 0 ? 'gk' : 'k'", { expr = true, silent = true })
vim.keymap.set('n', 'j', "v:count == 0 ? 'gj' : 'j'", { expr = true, silent = true })

vim.keymap.set('n', '[d', vim.diagnostic.goto_prev, { desc = 'Go to previous diagnostic message' })
vim.keymap.set('n', ']d', vim.diagnostic.goto_next, { desc = 'Go to next diagnostic message' })
vim.keymap.set('n', 'e', vim.diagnostic.open_float, { desc = 'Open floating diagnostic message' })
vim.keymap.set('n', 'q', vim.diagnostic.setloclist, { desc = 'Open diagnostics list' })

3

Even though RA works fine on my machine, I still get ERRORs emitted from RA like these.
So I think they just indicate RA is working and there is not a big deal. For example, RA emits a diagnostic for unused_imports in your log.

This doesn't matter neither. Because the command run in my nightly neovim tells me false too, but more importantly:

vim.lsp.buf.server_ready() is deprecated. :help deprecated
This feature will be removed in Nvim version 0.10
stack traceback:
        .../bin/nvim-linux64/share/nvim/runtime/lua/vim/lsp/buf.lua:37: in function 'server_ready'
        [string ":lua"]:1: in main chunk
false

and `:help deprecated` says
 LSP FUNCTIONS
 - vim.lsp.buf.server_ready()
   Use LspAttach instead, depending on your use-case. "Server ready" is not
   part of the LSP spec, so the Nvim LSP client cannot meaningfully implement
   it. "Ready" is ambiguous because:
   - Language servers may finish analyzing the workspace, but edits can always
     re-trigger analysis/builds.
   - Language servers can serve some requests even while processing changes.

Actually I rarely use builtin LSP lua functions to config LSP. Some reasons:

1 Like
4

"no current exe available" is not an error message that RA produces as far as I know. I suspect this is actually a build script in your project failing, maybe because of a different environment variable setup compared to how you run cargo check.

5

Thanks much. Maybe your reply (that I should use some plugins, that I didn't do enough config) also explains why omnifunc doesn't seem to be getting set and trying to set it manually with one command yields errors in nvim something like "unset" or "function not found". Sounds like I need to get comfortable with the world of neovim plugins. I have done a little web reading about plugins to use for this sort of thing, which partly overlaps with what you suggest. I also see at neovim.io that clicking on plugins leads to Trending Neovim Plugins in 2024 etc. Is there a better way that I am missing, in general, to stay on top of what plugins might best suit me? (Then there is the issue of which ones to trust and whether I'm going to read their code; as I gather that some popular browser plugins have had problems with being bought by unfriendly actors.)

Thanks very much.

6

Recommended reading includes:

1 Like
7

I would suggest starting from https://www.lazyvim.org/ because

  • it integrates the best, most handy & recent plugins out of the box, including LSP/autocompletion/fancy UI/etc
  • it classifies the priorities of plugins' loading to help reduce/limit startup time of neovim

If you want to start from a complete but least config example, check out GitHub - nvim-lua/kickstart.nvim: A launch point for your personal nvim configuration because it provides the skeleton layout and great tutorials.

2 Likes
8

I think it might be our message! We do use current_exe() to reexec ourselves for proc macros! And, if I am not mistaken, @lcall runs this on an unusual platform (BSD?) so there might be something funky here.

I suspect this is what fails:

@lcall this might require some extra debugging on your side, but I smell something interesting here!

Oh….. I now recall some discussion on whether BSD should at all have a syscall to reveal executables’ own path….

I wonder what we should do here to make it work?

For the context, what we do here is that we run cargo check, but with rust-analyzer masquerading as rustc, so that we can compile build scripts and nothing more

9

Oh, in that case disabling rust-analyzer.cargo.buildScripts.useRustcWrapper should fix the problem?

1 Like
10

I would suggest starting from https://www.lazyvim.org/ because ....
If you want to start from a complete but least config example, check out ... kickstart.nvim .

Thanks. I started studying the kickstart.nvim and found that mason has a problem where it can't run on OpenBSD. Not wanting to dive that deeply into learning enough lua and neovim details to debug it, I decided to comment out everything from kickstart.nvim and re-enable things one plugin at a time. So now in my init.lua I have lazy and neovim/nvim-lspconfig, and hopefully once I have those working I can add another and see how that goes. I hope it can work well enough without mason. I don't plan to immediately become a lua expert, if I can avoid it, but I don't mind studying the documentation for individual plugins to see how to set them up. I hope that strategy will work (along with reading some of the materials people have linked in other replies in this topic).

11

Thanks I plan to read those after the immediate issues are fixed and I can at least minimally use Rust with LSP (unless I need to read them sooner, as they are key inputs to my understanding how...).

12

I'm willing to debug things, try things, and provide info, but I'm not really a C or lua programmer. (I'm more into bash, and learning Rust, and whatever I can do in following clear instructions.) So, is that something I can test with setting a variable in neovim, or a simple change to my init.lua, or something?

Or, should try some test modifications (strategic pringln statements? whatever will get logged somewhere?) to the commit of RA I am using and try some things there to help diagnose? I'm currently using RA commit 424da1007, because OpenBSD 7.4 stable provides only rustc 1.72.1 (until May or so when the next OpenBSD version is released).

And, if that is the core issue, is it likely to arise regardless of whether I use RA and LSP from a plugin vs. trying to do it manually?

Thanks very much!

13

It turns out that a minimal enabling of neovim/nvim-lspconfig lets me do
i<C-x><C-o>
... in neovim and I now get a list of completions! And "verbose set omnifunc?" actually returns a value without my trying to set it manually. And I don't get the original error about "no current exe available", in the log file (just an error about something taking more than 100ms or something, which I think I can ignore).

So maybe it was not an issue in the rust-analyzer code itself, after all. Now I think I need to try learning or mapping more key combinations for RA features to try them and see what logic, other plugins, or other learning will do next. Suggestions still welcomed, as I study configs for the various suggestions given above. Thanks again.

14

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.