mfussenegger / nvim-lint

An asynchronous linter plugin for Neovim complementary to the built-in Language Server Protocol support.
GNU General Public License v3.0
2.02k stars 209 forks source link

All parsers relying on `from_errorformat` are broken #495

Closed stephen-huan closed 10 months ago

stephen-huan commented 10 months ago

3739681 introduces a new parameter bufnr that only displays the lint if the item buffer matches bufnr. This appears to breaks every parser relying on the require("lint.parser").from_errorformat pattern.

I personally bisected the error for the fish and statix linters. This is likely also the root cause of #481 and #492.

mfussenegger commented 10 months ago

I don't see how a change to from_errorformat would break from_pattern and several linters that use from_pattern work just fine for me.

Given that you didn't post any reproduction steps, or provided an actual error description I'm closing this.

stephen-huan commented 10 months ago

@mfussenegger for fish, the file

echo "$$"

fish --no-execute gives

temp.fish (line 1): $$ is not the pid. In fish, please use $fish_pid.
echo "$$"
       ^
warning: Error while reading file temp.fish

and indeed, the editor diagnostic shows

Diagnostics:
1. $$ is not the pid. In fish, please use $fish_pid.

as expected on commit 6f589cb93560581dc2a3b9693658afe865e5649e. On commit 373968190b0022be80a6099ecb483cfc2b5fe8af, it shows nothing. That is what I meant by bisection.

For statix, the file

{
  x = x;
}

with statix check gives

[W03] Warning: Assignment instead of inherit
   ╭─[temp.nix:2:3]
   │
 2 │   x = x;
   ·   ───┬──
   ·      ╰──── This assignment is better written with inherit
───╯

and the editor shows

This assignment is better written with `inherit`

Like fish, it shows the lint on the working commit, and fails to show on the next commit.

The thing that these linters have in common is they both use .from_errorformat.

stephen-huan commented 10 months ago

481 (php) also bisects to 373968190b0022be80a6099ecb483cfc2b5fe8af.

Consider the example used in the original issue

<?php

echo "Hello, world!" // Notice the missing semi-colon at the end of this line

Running php -l gives

Parse error: syntax error, unexpected end of file, expecting "," or ";" in temp.php on line 4
Errors parsing temp.php

and the editor shows

Diagnostics:
1. syntax error, unexpected end of file, expecting "," or ";"

Like fish and statix, it works on commit 6f589cb93560581dc2a3b9693658afe865e5649e but not on 373968190b0022be80a6099ecb483cfc2b5fe8af.

For #492 (cppcheck) I can't replicate the issue.

Consider

void foo(int x)
{
    int buf[10];
    if (x == 1000)
        buf[x] = 0; // <- ERROR
}

(note that a folder called build should also be created in the same directory). Running

cppcheck --enable=warning,style,performance,information --language=c++ --inline-suppr --quiet --cppcheck-build-dir=build --template="{file}:{line}:{column}: [{id}] {severity}: {message}" temp.cpp

gives

cppcheck: '--enable=information' will no longer implicitly enable 'missingInclude' starting with 2.16. Please enable it explicitly if you require it.
/home/ikue/temp.cpp:5:12: [arrayIndexOutOfBoundsCond] warning: Either the condition 'x==1000' is redundant or the array 'buf[10]' is accessed at index 1000, which is out of bounds.
/home/ikue/temp.cpp:3:9: [variableScope] style: The scope of the variable 'buf' can be reduced.
/home/ikue/temp.cpp:5:16: [unreadVariable] style: Variable 'buf[x]' is assigned a value that is never used.

and the editor shows

temp.cpp|3 col 9 info| The scope of the variable 'buf' can be reduced.
temp.cpp|5 col 12 warning| Either the condition 'x==1000' is redundant or the array 'buf[10]' is accessed at index 1000, which is out of bounds.
temp.cpp|5 col 16 info| Variable 'buf[x]' is assigned a value that is never used.

This works on latest master (f98b1efe0d20b98b64fd0fd117435883b5c22eb3).

stephen-huan commented 10 months ago

Sorry for the noise, but I just realized where the confusion lies. I meant from_errorformat, not from_pattern. I mixed the two up when writing the issue, and that's why I can't replicate the cppcheck issue (it uses from_pattern).

A cursory search shows that the actual list of (possibly) affected linters are