[windows] rust-analyzer attaches but it is not working

[alex-ds13]

Neovim version (nvim -v)

NVIM v0.10.0-dev-2507+g3df1211eb

Operating system/version

Windows 11

Output of :checkhealth rustaceanvim

rustaceanvim: require("rustaceanvim.health").check()

Checking for Lua dependencies ~
- WARNING dap not installed. Needed for debugging features [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap)

Checking external dependencies ~
- OK rust-analyzer: found rust-analyzer 0.3.1868-standalone (037924c4d 2024-03-03)
- OK Cargo: found 
- OK rustc: found 

Checking config ~
- OK No errors found in config.

Checking for conflicting plugins ~
- OK No conflicting plugins detected.

Checking for tree-sitter parser ~
- OK tree-sitter parser for Rust detected.

How to reproduce the issue

open any rust project
wait for rust-analyzer to load
try to use any LSP features like hover, go-to-definition...

Expected behaviour

Expected the LSP to work after initialization

Actual behaviour

No LSP features work after initialization. There is nothing showing on the rust-analyzer log file (it is empty).

I've traced this to the commit e536434.

The problem is the following change on the lua/rustaceanvim/lsp.lua file:

M.start = function(bufnr)
  bufnr = bufnr or vim.api.nvim_get_current_buf()
  local client_config = config.server
  ---@type LspStartConfig
  local lsp_start_config = vim.tbl_deep_extend('force', {}, client_config)
  local root_dir = cargo.get_root_dir(vim.api.nvim_buf_get_name(bufnr))
-  root_dir = root_dir and normalize_path(root_dir)
+  root_dir = root_dir and os.normalize_path(root_dir)
  lsp_start_config.root_dir = root_dir
  if not root_dir then

Somehow the old normalize_path function that only change the drive letter to lowercase works, but the new normalize function that lowercase's the entire path doesn't. I can't quite figure out why, but I've tested it locally and changing that line is what makes the difference (considering the old normalize_path function is still on the lsp.lua file).

I don't know if it has anything to do with the fact that vim.api.nvim_buf_get_name(buf_nr) returns the path that way, with only the drive letter as lowercase? I've tried looking if the internals of neovim lsp by any chance are using this function to get the client, but doesn't seem like it. So right now I have no clue...

Maybe you might find out whats happening.

The minimal config used to reproduce this issue.

-- Minimal nvim config with lazy
-- Assumes a directory in $NVIM_DATA_MINIMAL
-- Start with
--
-- export NVIM_DATA_MINIMAL=$(mktemp -d)
-- export NVIM_APP_NAME="nvim-ht-minimal"
-- nvim -u minimal.lua
--
-- Then exit out of neovim and start again.

-- Ignore default config
local config_path = vim.fn.stdpath('config')
vim.opt.rtp:remove(config_path)

-- Ignore default plugins
local data_path = vim.fn.stdpath('data')
local pack_path = data_path .. '/site'
vim.opt.packpath:remove(pack_path)

-- bootstrap lazy.nvim
data_path = assert(os.getenv('NVIM_DATA_MINIMAL'), '$NVIM_DATA_MINIMAL environment variable not set!')
local lazypath = data_path .. '/lazy/lazy.nvim'
if not vim.uv.fs_stat(lazypath) then
  vim.fn.system {
    'git',
    'clone',
    '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git',
    '--branch=stable',
    lazypath,
  }
end
vim.opt.rtp:prepend(lazypath)

local lazy = require('lazy')

local on_attach = function(client, bufnr)
    -- Mappings.
    -- See `:help vim.lsp.*` for documentation on any of the below functions
    local bufopts = { silent=true, buffer=bufnr, noremap = true }
    vim.keymap.set('n', 'gd', vim.lsp.buf.definition, bufopts)
    vim.keymap.set('n', 'K', vim.lsp.buf.hover, bufopts)
end

lazy.setup({
  {
    'mrcjkb/rustaceanvim',
    version = '^4',
    init = function()
      -- Configure rustaceanvim here
      local logfile = vim.fn.tempname() .. '-rust-analyzer.log'
      vim.g.rustaceanvim = {
          server = {
              on_attach = on_attach,
              -- capabilities = cmp_capabilities,
              cmd = function()
                  return { 'rust-analyzer.cmd', '--log-file', logfile }
              end,
              logfile = logfile,
              default_settings = {
                  ['rust-analyzer'] = {
                      files = {
                          excludeDirs = {'./target'},
                      },
                  },
              },
          },
          tools = {
              enable_clippy = true,
              -- on_initialized = function(_)
              --     -- Runs after rust-analyzer finishes initialization
              --     ih.set_all()
              -- end,
          },
      }
    end,
    ft = { 'rust' },
  },
  {
      "williamboman/mason.nvim",
      init = function ()
        require('mason').setup()
      end
  },
  -- Add any other plugins needed to reproduce the issue.
  -- see https://github.com/folke/lazy.nvim#-lazynvim for details.
}, { root = data_path, state = data_path .. '/lazy-state.json', lockfile = data_path .. '/lazy-lock.json' })

[mrcjkb]

Hey 👋
Thanks for the detailed report.

Strange, I thought Windows paths were case insensitive. I guess We can normalise only the drive letter then...

[alex-ds13]

Hey 👋 Thanks for the detailed report.

Strange, I thought Windows paths were case insensitive. I guess We can normalise only the drive letter then...

What's even stranger is that I'm pretty sure that I've had a version of rustaceanvim higher than 4.7.5 (might have been version 4.10) for a couple of days now and it had this problem but it wasn't every time! Sometimes it took a while longer after initialization but it started working. But now with version 4.11 it never works.

I don't see any other commit that might have change this in since the one on version 4.8.0, so it really is weird..

[mrcjkb]

4.11.0 introduced a feature where the client doesn't auto-attach to buffers that aren't actual files.
But if the client is attaching, as you describe, I don't see how that can be the problem (unless it's somehow a combination of the two changes).

Anyways, I've changed it to only lower-case the drive letter: 387ca84

Let me know if that fixes it 😄

[alex-ds13]

4.11.0 introduced a feature where the client doesn't auto-attach to buffers that aren't actual files. But if the client is attaching, as you describe, I don't see how that can be the problem (unless it's somehow a combination of the two changes).

Anyways, I've changed it to only lower-case the drive letter: 387ca84

Let me know if that fixes it 😄

That does fix it! 😄 Thank you!

I've really tried to understand why is this happening but couldn't figure it out. I also found it weird that no one else had created an issue about it yet. Was it really just me? If so there had to be something different on my end, but the only thing that I have that might be different is that I'm using Mason's version of rust-analyzer but I don't think that's the issue...

[mrcjkb]

Maybe there's just less Windows/Neovim users. The 4.11.0 release was just yesterday.
Anyways, I'm glad it's working now 😄

[TheRustifyer]

Just for the sake of completness, I run yesterday into the same issue, and anything was working (neither runnnables/testables/debuggables) was being loaded correctly (only the check --workspace entries)

I was unable to reproduce the issue on my Unix based setup, after facing this on my Windows machine. After updating to the v4.11 everything is working again on Windows.

Thanks for the catch @alex-ds13 and @mrcjkb for the quick update!