bug: LSP diagnostic set to wrong error level
pidgeon777 opened this issue · comments
Neovim version (nvim -v)
v0.9.2
Operating system/version
Windows 10 Pro
Describe the bug
This is my on_output_quickfix error format:
errorformat = "%f:%l:%c:%s:(report %tote): %m,%f:%l:%c:%tarning: %m,%f:%l:%c: %m",Problem is that when one of those strings is parsed in command output:
XY_Decimation/RESIZER_XY_TB.vhd:287:17:@0ms:(report note): X_SIZE = 32
then the rescpective diagnostic lines are set as error, and not info/note:
Steps To Reproduce
See above.
Expected Behavior
I would expect the vim.lsp.diagnostic obtained lines to be shown with the info/note type, not error.
Also (another possible bug) the cnext and cprevious commands doesn't actually move the cursor under those circumstances.
I believe this was related to the behavior in on_result_diagnostics, and I've pushed up what is probably a fix. It's hard to say exactly because I don't know what task you're running, what components are on the task, or what parameters you're using on the components.
As for cnext and cprev not working, I don't know what's going on there but you can inspect the quickfix items with :=vim.fn.getqflist(). If there's something incorrect about the items then we may be able to find out where the bad value is being set.
I believe this was related to the behavior in on_result_diagnostics, and I've pushed up what is probably a fix.
The fix, fixed it 👍.
As for cnext and cprev not working, I don't know what's going on there but you can inspect the quickfix items with :=vim.fn.getqflist(). If there's something incorrect about the items then we may be able to find out where the bad value is being set.
Result of :lua=vim.fn.getqflist() is:
{ {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 284,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "STARTING TESTBENCH",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 286,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "PRJ_P = C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 287,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "X_SIZE = 32",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 288,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "Y_SIZE = 32",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 289,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "X_SIZE_OUT = 8",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 290,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "Y_SIZE_OUT = 8",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 291,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "X_SIZE_W = 6",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 292,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "Y_SIZE_W = 6",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 293,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "DATA_WIDTH = 8",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 295,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "PGM_IN_P = C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\Resizer\\Src\\32x32\\Img\\output.pgm",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 296,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "CODE_INDEX_X_P = C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\Resizer\\Src\\32x32\\LUT\\test\\code_index_x_tb.txt",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 15,
col = 17,
end_col = 0,
end_lnum = 0,
lnum = 297,
module = "",
nr = -1,
pattern = "^\\V@0ms\\$",
text = "CODE_INDEX_Y_P = C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\Resizer\\Src\\32x32\\LUT\\test\\code_index_y_tb.txt",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 31,
col = 25,
end_col = 0,
end_lnum = 0,
lnum = 214,
module = "",
nr = -1,
pattern = "^\\V@1897ns\\$",
text = "[PGM_READER] Starting reading file! Path: C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\Resizer\\Src\\32x32\\Img\\output.pgm",
type = "n",
valid = 1,
vcol = 0
}, {
bufnr = 31,
col = 25,
end_col = 0,
end_lnum = 0,
lnum = 260,
module = "",
nr = -1,
pattern = "^\\V@7332ns\\$",
text = "[PGM_READER] Done reading file! Path: C:\\Work\\Projects\\HDL\\Simulations\\Active-HDL_11.1\\LIB_HDL\\LIB_HDL\\Resizer\\Src\\32x32\\Img\\output.pgm",
type = "n",
valid = 1,
vcol = 0
} }Strange thing is that if I manually focus one of the quickfix elements (rows) and press Enter, then the cursor moves to the selected quickfix element position.
But cnext and cprevious commands only moves the focused quickfix row up and down, withouth moving also the cursor (it stays on the same position in the currently active buffer), unless the quickfix element is pointing to a different buffer than the actual one. Then the commands make the cursor switch to the newly selected buffer, but again as if the line and column fields of each quickfix element are skipped, taking only buffer path into consideration.
I hope to have explained the issue in clear terms.
The problem is that your quickfix items have both a lnum/col and a pattern. From :help errorformat:
When the pattern is present the line number will not be used.
You're using %s in your errorformat which captures a search string. In theory this allows you to jump around without explicit line/column numbers which is more robust when you've made changes to the file. In practice, the search pattern does not seem to match anything in your file. I'd recommend removing the %s or massaging the errorformat until it captures a correct pattern.
Ouch, didn't know that! Nice catch 👍.
I updated the errorformat string removing the %s and now it works as expected.