Clippy checking not injected into default configuration

[JeanMertz]

Have you read the docs and searched existing issues?

• I have read the README's troubleshooting guide and FAQ(https://github.com/mrcjkb/rustaceanvim?tab=readme-ov-file#left_speech_bubble-faq).
• I am using the latest rustaceanvim release.
• I have searched existing issues.
• I have searched existing discussions.
• I have searched the existing issues of other plugins related to this issue (if applicable).
• I have searched the existing rust-analyzer issues (if applicable).
• I can reproduce the issue with stable Neovim (not a distribution or nightly) and the minimal config.
• This is an issue about rustaceanvim, not rust-analyzer or Neovim.
• This is not an issue with autocompletion.

Neovim version (nvim -v)

n/a

Operating system/version

n/a

Output of :checkhealth rustaceanvim

n/a

How to reproduce the issue

n/a

Expected behaviour

This is a follow-up to #650. I couldn't reply there because it was locked as off-topic (correctly, with the given information at the time). I did some more debugging and have concluded that the issue is specific to rustaceanvim (or at least, to my usage of rustaceanvim, likely).

The issue seems to be that the default configuration did not correctly set the linter to clippy, instead defaulting to check.

I verified this by (1) migrating to nvim-lint and running cargo clippy directly, which worked, then (2) migrating to nvim-lspconfig and explicitly setting check.command to clippy, which also worked, and then finally (3) migrating back to rustaceanvim and also setting that command explicitly, which made things work as well.

Things I did to figure out what was happening:

• Explicitly set tools.enable_clippy to true (no difference, as expected)
• :lua vim.print(vim.fn.executable('cargo-clippy') == 1) (returned true)
• Make sure I don't have a custom check/checkOnSave set (I didn't)
• :lua vim.print(require('rustaceanvim.config.internal'))

Here's relevant parts of that last one:

vim.print(require('rustaceanvim.config.internal').tools.enable_clippy)
-- true

vim.print(require('rustaceanvim.config.internal').server.default_settings)
-- {
--   ["rust-analyzer"] = {}
-- }

vim.print(require('rustaceanvim.config.internal').server.settings)
{
--   ["rust-analyzer"] = {
--     inlayHints = {
--       bindingModeHints = {
--         enable = false
--       },
--       chainingHints = {
--         enable = true
--       },
--       closingBraceHints = {
--         enable = true,
--         minLines = 25
--       },
--       closureReturnTypeHints = {
--         enable = "never"
--       },
--       lifetimeElisionHints = {
--         enable = "never",
--         useParameterNames = false
--       },
--       maxLength = 25,
--       parameterHints = {
--         enable = true
--       },
--       reborrowHints = {
--         enable = "never"
--       },
--       renderColons = true,
--       typeHints = {
--         enable = true,
--         hideClosureInitialization = false,
--         hideNamedConstructor = false
--       }
--     }
--   }
-- }

Aside from the server settings, I also set this:

{ 
   tools = {
        code_actions = {
            ui_select_fallback = true,
        },
        test_executor = "background",
    }
}

Somewhere, somehow, the configuration decides not to inject the command = clippy default setting. I don't know exactly why or where, but I'm sure you'll have more contextual knowledge to understand what is going on here.

I've resolved it for now by manually forcing the clippy command in the config, but perhaps this issue allows you to find a potential bug and help avoid others walking into this trap.

Actual behaviour

n/a

The minimal config used to reproduce this issue.

n/a

[mrcjkb]

🤔 the checkhealth output in #650 says

- OK .vscode/settings.json loaded without errors.

Could that be the culprit?

[JeanMertz]

Could that be the culprit?

There is no .vscode/settings.json file actually. I assumed that was just a fallback message when no file existed.

I'll dig into the code to see which paths it looks at, to see if there's something somewhere that shouldn't be there.

[JeanMertz]

Looking at this:

rustaceanvim/lua/rustaceanvim/lsp/init.lua

Lines 43 to 48 in 10efd4d

	local function find_vscode_settings(bufname)
	local settings = {}
	local found_dirs = vim.fs.find({ '.vscode' }, { upward = true, path = vim.fs.dirname(bufname), type = 'directory' })
	if vim.tbl_isempty(found_dirs) then
	return settings
	end

If I run this:

vim.fs.find({ '.vscode' }, { upward = true, path = vim.fs.dirname(bufname), type = 'directory' })

It returns an empty table. Which then returns an empty table here:

rustaceanvim/lua/rustaceanvim/lsp/init.lua

Lines 46 to 48 in 10efd4d

	if vim.tbl_isempty(found_dirs) then
	return settings
	end

That is used here:

rustaceanvim/lua/rustaceanvim/lsp/init.lua

Lines 69 to 72 in 10efd4d

	if config.server.load_vscode_settings then
	local json_settings = find_vscode_settings(bufname)
	require('rustaceanvim.config.json').override_with_rust_analyzer_json_keys(evaluated_settings, json_settings)
	end

Which triggers this:

rustaceanvim/lua/rustaceanvim/config/json.lua

Lines 75 to 79 in 10efd4d

	function M.override_with_rust_analyzer_json_keys(tbl, json_tbl)
	M.override_with_json_keys(tbl, json_tbl, function(key)
	return vim.startswith(key, 'rust-analyzer')
	end)
	end

Which triggers this:

rustaceanvim/lua/rustaceanvim/config/json.lua

Lines 64 to 71 in 10efd4d

	function M.override_with_json_keys(tbl, json_tbl, key_predicate)
	is_json_config_loaded = true
	for json_key, value in pairs(json_tbl) do
	if not key_predicate or key_predicate(json_key) then
	override_tbl_values(tbl, json_key, value)
	end
	end
	end

Which then sets is_json_config_loaded = true, even though it was an empty table because there was no JSON.

That then triggers the "loaded vscode json" message in the healthcheck. So I don't believe that's relevant in this case, unless the fact that it things an (empty) vscode file was loaded makes it not inject the check config, but I haven't checked if that's the case.

[JeanMertz]

Forcing server.load_vscode_settings to false removes that line from checkhealth, but does not fix my issue.

[mrcjkb]

thanks for the detailed analysis 🙏

[JeanMertz]

I'll clone this repo sometime tomorrow and add some debug statements, to see what's happening and why the default check configuration isn't being integrated into the global config.