Closed Per48edjes closed 10 months ago
Hi. Can you reproduce this with a minimal config? If you can't, try adding the plugins you use, until you can.
Usually, UnhandledPromiseRejection
with an LSP error is caused by a plugin or an autocommand trying to use LSP capabilities without properly checking if the language server supports them, or without proper error handling.
Does the error message appear while you're in insert mode? If so, it might be a completion plugin.
for now it seems to happen whenever I'm writing out a type signature but have yet to give a value-level definition
This could be an indicator that a plugin or an autocommand is calling something like vim.lsp.buf.format
(or something else) that fails if haskell-language-server
can't parse the code properly.
And don't worry about "being a bother" when reporting potential bugs 😄
Will give it a go with the minimal config...one additional observation in the meanwhile is this is triggered when I escape out of insert mode (back to normal mode) if ill-formed Haskell is introduced while in insert mode.
FWIW, this behavior doesn't seem to occur when I'm developing in other languages (tested with C and Python) with the same Neovim set up.
FWIW, this behavior doesn't seem to occur when I'm developing in other languages (tested with C and Python) with the same Neovim set up.
The error is thrown by haskell-language-server
- specifically, the hls-code-range-plugin
, which provides the selection-range and folding-range features.
That's why you're not getting it with other languages.
when I escape out of insert mode (back to normal mode)
This tells me that you (or a plugin) must have an autocommand set up that executes something that causes the error to be thrown on an InsertLeave
event.
haskell-tools
does set up an autocommand for the InsertLeave
event, which refreshes code-lenses. But the hls-code-range-plugin
does not provide any code lenses, so I don't see how that could cause the error in your screen shot.
Does calling :lua vim.lsp.codelens.refresh()
result in the error?
A likely culprit that might be causing error messages from the hls-code-range-plugin
would be nvim-ufo
: It sets up an autocommand on InsertLeave
that updates folds, which uses the folding-range feature, provided by the hls-code-range-plugin
.
You can check which autocommands are active by running :autocmd
.
Or, to see where it is defined, you can run something like: :verbose autocmd InsertLeave
Does calling :lua vim.lsp.codelens.refresh() result in the error?
Doesn't seem so!
Also, that was great sleuthing -- when I disable nvim-ufo
(with :UfoDisable
) the issue goes away.
Hmm, interesting.
What's the output of :checkhealth haskell-tools
?
Asking because I use nvim-ufo
, and don't have the same error on InsertLeave
. So this might be hard for the nvim-ufo
author to reproduce.
It could also be a bug in the haskell-language-server
version you're using. You could find that out by trying to reproduce it in VSCode with the same version.
Maybe you need to register foldingRange
capabilities.
https://github.com/kevinhwang91/nvim-ufo#minimal-configuration
Although I think nvim-ufo should be checking both the server and client capabilities.
I've just pushed a release that automatically adds foldingRange
capabilities if nvim-ufo
is installed: https://github.com/mrcjkb/haskell-tools.nvim/pull/254
Maybe that will solve the issue for you?
Hmmmm...I updated to #254 , but the issue is still persisting for me 😞 .
:checkhealth
looks good; see output reproduced below.haskell-tools: require("haskell-tools.health").check()
Checking for Lua dependencies ~
- OK [nvim-lua/plenary.nvim](https://github.com/nvim-lua/plenary.nvim) installed.
- OK [nvim-telescope/telescope.nvim](https://github.com/nvim-telescope/telescope.nvim) installed.
Checking external dependencies ~
- OK haskell-language-server: found haskell-language-server version: 2.2.0.0 (GHC: 8.10.7) (PATH: /Users/rdayabhai/.local/share/nvim/mason/packages/haskell-language-server/lib/haskell-language-server-2.2.0.0/bin/haskell-language-server-wrapper)
- WARNING hoogle: not found.
Install [ndmitchell/hoogle](https://github.com/ndmitchell/hoogle) for extended capabilities.
Recommended for better Hoogle search performance.
Without a local installation, the web API will be used by default.
Required if the hoogle mode is set to "telescope-local".
- WARNING fast-tags: not found.
Install [fast-tags](https://hackage.haskell.org/package/fast-tags) for extended capabilities.
Optional, for generating tags as a `tagfunc` fallback.
- OK curl: found curl 7.85.0 (x86_64-apple-darwin22.0) libcurl/7.85.0 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.47.0
- OK haskell-debug-adapter: found haskell-debug-adapter-0.0.38.0
- OK ghci-dap: found The Glorious Glasgow Haskell Compilation System, version 9.2.7
Checking config ~
- OK No errors found in config.
Hmm, I'm using haskell-language-server
version 2.0.0.1. So maybe it's a haskell-language-server
bug?
Tried rolling back to v2.0.0.1...same error still gets thrown!
Can you reproduce the same behaviour in VSCode? (trying to figure out if it's an issue with haskell-language-server on MacOS or nvim-ufo). I'm afraid I don't own a mac, so I can't do this myself :disappointed:
In the meantime, as a workaround, you can disable LSP-based folding (and use treesitter instead) for Haskell files in nvim-ufo:
require('ufo').setup {
provider_selector = function(filetype)
if filetype == 'haskell' then
return { 'treesitter', 'indent' }
end
return nil -- use default
end,
-- other options...
}
By the way, you might be able to see exactly where the error is thrown in nvim-ufo if you can reproduce it by calling:
:lua require('ufo.fold').update(0)
I think that's the function that is wrapped in vim.schedule
, and because it's wrapped, we don't see the exact location.
Just downloaded VSCode and installed the following extensions:
The language server seems to work fine -- wasn't able to reproduce the bug with the Vim
extension enabled... Let me give your most recent suggestion a shot!
By the way, you might be able to see exactly where the error is thrown in nvim-ufo if you can reproduce it by calling:
:lua require('ufo.fold').update(0)
I think that's the function that is wrapped in
vim.schedule
, and because it's wrapped, we don't see the exact location.
Hmmm, running that command doesn't do anything as far as I can tell... 🤔 It really only rears its head on that InsertLeave
event.
Interestingly, running this command does reproduce the bug:
:lua require('ufo.lib.event'):emit('InsertLeave', vim.api.nvim_get_current_buf())
In the meantime, as a workaround, you can disable LSP-based folding (and use treesitter instead) for Haskell files in nvim-ufo:
require('ufo').setup { provider_selector = function(filetype) if filetype == 'haskell' then return { 'treesitter', 'indent' } end return nil -- use default end, -- other options... }
Updated my config with this... 🥁 ...and the issue still persists. 😆
Interesting. So if you run
:autocmd! Ufo InsertLeave *
which should disable nvim-ufo's autocommand, you don't get the error and you can use nvim-ufo to fold/unfold manually?
Interestingly, running this command does reproduce the bug
Hmm, and I guess it reproduces it while not in insert mode?
I'm off for today, but I'll see if that passes any other callbacks to vim.schedule
in the next few days.
Will give it a go with the minimal config...
Forgot about this... Were you able to reproduce it with a minimal config (that includes nvim-ufo)? - just to make sure there's not a third plugin causing this...
I'm off for today, but I'll see if that passes any other callbacks passed to vim.schedule in the next few days.
I can't tell you how much I appreciate the help / hand-holding, @mrcjkb ... thank you so very much!
Interesting. So if you run
:autocmd! Ufo InsertLeave *
which should disable nvim-ufo's autocommand, you don't get the error and you can use nvim-ufo to fold/unfold manually?
Not quite. I run :autocmd! Ufo InsertLeave *
, but the same, wonky error is raised.
Hmm, and I guess it reproduces it while not in insert mode?
Yep, exactly.
Forgot about this... Were you able to reproduce it with a minimal config (that includes nvim-ufo)? - just to make sure there's not a third plugin causing this...
Working on this now (slipped through the cracks for me, too -- my fault!)...
With the minimal config as-is (i.e., without nvim-ufo
), the error cannot be replicated.
With the minimal config and nvim-ufo
installed (using tree-sitter
as the main provider), the error cannot be replicated.
With the minimal config and nvim-ufo
+ nvim-lspconfig
(using the LSP as the main provider), the error is replicated:
See here for the actual config used to replicate:
:thinking: I still can't reproduce it on my device with the minimal config you posted.
But judging by the following snippet:
local language_servers = require("lspconfig").util.available_servers() -- or list servers manually like {'gopls', 'clangd'}
for _, ls in ipairs(language_servers) do
require('lspconfig')[ls].setup({
capabilities = capabilities
-- you can add other fields for setting up lsp server in this table
})
For me (with your minimal config), require("lspconfig").util.available_servers()
returns an empty table
.
But maybe in yours it somehow includes hls
(which is the lspconfig
configuration for haskell-language-server
)?
If this is the case, then calling require('lspconfig').hls.setup()
could indeed lead to a conflict.
But your astrocommunity PR (https://github.com/AstroNvim/astrocommunity/pull/553) didn't remove
astronvim.lsp.skip_setup = utils.list_insert_unique(astronvim.lsp.skip_setup, "hls")
so I don't see how that could be happening.
Can you check if the client for hls
is running by calling :LspInfo
, or if hls
has been set up by calling
:lua =vim.api.nvim_get_autocmds({ event = 'FileType', group = 'lspconfig' , pattern = 'haskell' })
🤔 I still can't reproduce it on my device with the minimal config you posted.
Yiiiiiikes. 🤯 Here's what's even more befuddling: I left a couple of the test buffers open for a while and came back to them...and the error stops getting thrown. But then I restart NeoVim, and the issue resurfaces.
(Note all of the observations below are for my regular, AstroVim setup.)
Here are the attached clients per :LspInfo
:
Language client log: /Users/rdayabhai/.local/state/nvim/lsp.log
Detected filetype: haskell
3 client(s) attached to this buffer:
Client: haskell-tools.nvim (id: 1, bufnr: [1])
filetypes:
autostart: false
root directory: /Users/rdayabhai/code/Simple-Haskell-Handbook
cmd: haskell-language-server-wrapper --lsp --logfile /Users/rdayabhai/.local/state/nvim/haskell-language-server.log
Client: null-ls (id: 2, bufnr: [1])
filetypes: luau, lua, css, vue, typescriptreact, graphql, markdown.mdx, handlebars, typescript, javascriptreact, markdown, javascript, json, jsonc, scss, less, yaml, html, python, sh, haskell
autostart: false
root directory: /Users/rdayabhai/code/Simple-Haskell-Handbook
cmd: <function>
Client: copilot (id: 3, bufnr: [1])
filetypes:
autostart: false
root directory: /Users/rdayabhai/code/Simple-Haskell-Handbook
cmd: node /Users/rdayabhai/.local/share/nvim/lazy/copilot.lua/copilot/index.js
Configured servers list: clangd, pyright, ruff_lsp, bashls, dockerls, yamlls, marksman, jsonls, lua_ls
When I run :lua =vim.api.nvim_get_autocmds({ event = 'FileType', group = 'lspconfig' , pattern = 'haskell' })
, an empty table is returned: {}
.
Yiiiiiikes.
Yup, that was my reaction, too.
I left a couple of the test buffers open for a while and came back to them...and the error stops getting thrown. But then I restart NeoVim, and the issue resurfaces.
Thanks for the outputs. It looks like lspconfig isn't the culprit either. Let's try some more scenarios:
nvim-ufo
+ nvim-lspconfig
(using the LSP as the main provider) - without haskell-tools (you will need to call require('lspconfig').hls.setup {}
in the minimal config, and disable the haskell-tools plugin).nvim-ufo
+ haskell-tools
(using the LSP as the main provider) - without lspconfigWe can try and find out what is causing haskell-language-server
to throw the error with the following steps:
vim.g.haskell_tools.hls.debug = true
=require('haskell-tools').log.get_hls_logfile()
:lua require('haskell-tools').log.nvim_open_hls_logfile()
Followed those steps (with the current AstroNvim set up), see below for the log output:
Will try those other scenarios later today!
Will try those other scenarios later today!
:pray:
/Users/rdayabhai/code/Simple-Haskell-Handbook/.stack-work/
Hmm, maybe it's project-specific? I've been trying to reproduce it with a test file that is not part of a project. I just tried with a Stack project, too, but to no avail, unfortunately.
Is the project you're working with available online? Does the error also occur in non-project files?
Hmm, maybe it's project-specific? Does the error also occur in non-project files?
Definitely not project-specific ... the error shows up for all projects and even standalone *.hs
.
Is the project you're working with available online?
More fun facts: running :UfoDisableFold
(vs. :UfoDisable
from earlier) also seems sufficient to stop the error.
Minimal config and nvim-ufo + nvim-lspconfig (using the LSP as the main provider) - without haskell-tools (you will need to call require('lspconfig').hls.setup {} in the minimal config, and disable the haskell-tools plugin).
Error persists under this scenario!
Minimal config and nvim-ufo + haskell-tools (using the LSP as the main provider) - without lspconfig
Wasn't 100% sure how to set this up in the minimal config, but here is what I ended up with.
...and the error still persists in this case, too!
Thus far, my working hypothesis is it has something to do with nvim-ufo
& haskell-language-server
interaction; perhaps, my nvim-ufo
config is borked? I'm using the out-of-box config from AstroNvim for that.
Yup, that's my current hypothesis, too.
One thing I just noticed from your :checkhealth
call:
Checking external dependencies ~
- OK haskell-language-server: found haskell-language-server version: 2.2.0.0 (GHC: 8.10.7) (PATH: /Users/rdayabhai/.local/share/nvim/mason/packages/haskell-language-server/lib/haskell-language-server-2.2.0.0/bin/haskell-language-server-wrapper)
You're using GHC 8.10.7 - I'm on GHC 9.4.6. Maybe that's why I can't reproduce it. I'm trying to build hls from source with GHC 8.10.7 now...
...and it failed.
How do you install hls? I guess AstoNVim uses a prebuilt binary downloaded by mason.nvim? Or are you using HomeBrew?
How do you install hls? I guess AstoNVim uses a prebuilt binary downloaded by mason.nvim?
Yep, mason.nvim
to manage HLS that gets called by NeoVim. Otherwise, I'm using GHCup to manage the Haskell toolchain.
Ah, ghcup
(which mason uses, too) is broken on NixOS, so I can't try that.
And the log you posted says it was using GHC 9.2.8, so it's unlikely to be the GHC version either.
I'll see if I can find something in the ufo config. But I fear I'm starting to run out of ideas...
You and me both, brother. 🥲 One thing (once I'm back at my desk) I want to try is a full reinstall of managed packages (via Mason
)...that or some sort of "rollback" to a previous state of affairs (clearly, not a fully baked idea 😄 )? 🤞🏽
Nope, I couldn't reproduce it with the AstroNVim config either.
But this looks interesting:
provider_selector = function(_, filetype, buftype)
local function handleFallbackException(bufnr, err, providerName)
if type(err) == "string" and err:match "UfoFallbackException" then
return require("ufo").getFolds(bufnr, providerName)
else
return require("promise").reject(err)
end
end
return (filetype == "" or buftype == "nofile") and "indent" -- only use indent until a file is opened
or function(bufnr)
return require("ufo")
.getFolds(bufnr, "lsp")
:catch(function(err) return handleFallbackException(bufnr, err, "treesitter") end)
:catch(function(err) return handleFallbackException(bufnr, err, "indent") end)
end
end,
Specifically, the line
return require("promise").reject(err)
I think that could be where the error is thrown in AstroNVim, so as a workaround, you could try replacing that line with something like
return require("ufo").getFolds(bufnr, 'treesitter')
or
return require("ufo").getFolds(bufnr, 'indent')
If that works, then the next step would be to figure out why nvim-ufo isn't throwing a UfoFallbackException
...
Huzzah! I may have just found the bug in nvim-ufo.
In nvim-ufo:
if code == errorCodes.RequestCancelled or code == errorCodes.ContentModified then
reject('UfoFallbackException')
else
reject(err)
end
toErrorCode (PluginRuleFailed _) = InL LSPErrorCodes_RequestFailed
and
PluginRuleFailed rule -> "Rule Failed:" <+> pretty rule
😲 👏🏽 🙌🏽 THIS WORKED!!! 🎉 🎆 🍾
Seriously, thank you @mrcjkb , SO much for jumping down this rabbit hole with me and doggedly chasing down this bug. 🙏🏽 I was about to blow up my entire set-up and start from nil... 😬
🎉🎉🎉
No problem 😅 Thanks to you too. I would have probably encountered it myself, eventually.
Question
{ Sorry to be such a bother! }
Since updating to
2.x.x.
, I'm getting this error:I'm still trying to figure out how to consistently replicate it, but for now it seems to happen whenever I'm writing out a type signature but have yet to give a value-level definition:
Just wondering if you think this is a
haskell-tools.nvim
config issue or perhaps something to do with the language server itself?(My current config is exactly the one introduced in AstroNvim/astrocommunity#553.)