You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your feature request related to a problem? Please describe.
In in March 2021 we landed #1861 which changed how compilation errors was handled by golangci-lint (see #1859 for an example of the improvement). This work was done as a followup of people not understanding why they couldn't lint their code when it didn't compile.
The result was, simply explained, to introduce typecheck which acts as a linter but is more of a front-end of the compilation errors. This helped users to see where the compiler pointed at in the code for such compilation errors. Of course, this is just as good as the compiler itself and a lot of compilation issues will not properly show where in the code your error lies. Furthermore one compilation error may often lead to many others making the output look like it contains a lot of issues.
Even though this made us able to see the compilation errors, many users are still not aware about the fact that that's what they are - errors compiling the code. Many users gets frustrated and try to disable the linter (which obviously isn't possible) and a common response from the maintainers is that "typecheck is not a real linter"
Describe the solution you'd like.
I think we should start by improving the documentation and better explain what typecheck is. We should also clarify that it's not possible to disable this "linter". It may also be a good idea to remove it from the list of linters.
Continuing replying that "typecheck is not a real linter"
Additional context.
No response
Suggested troubleshooting documentation
In addition to describing what typecheck is and why it can't be disabled it would be useful to list some common things to try to find the root cause. Some examples would be
Ensure building works with go build ./... - whole package
Ensure all C dependencies are installed if using CGO
Ensure the version of golangci-lint is built with a compatible version of the repo - always try latest
The text was updated successfully, but these errors were encountered:
Your feature request related to a problem? Please describe.
In in March 2021 we landed #1861 which changed how compilation errors was handled by
golangci-lint
(see #1859 for an example of the improvement). This work was done as a followup of people not understanding why they couldn't lint their code when it didn't compile.The result was, simply explained, to introduce
typecheck
which acts as a linter but is more of a front-end of the compilation errors. This helped users to see where the compiler pointed at in the code for such compilation errors. Of course, this is just as good as the compiler itself and a lot of compilation issues will not properly show where in the code your error lies. Furthermore one compilation error may often lead to many others making the output look like it contains a lot of issues.Even though this made us able to see the compilation errors, many users are still not aware about the fact that that's what they are - errors compiling the code. Many users gets frustrated and try to disable the linter (which obviously isn't possible) and a common response from the maintainers is that "
typecheck
is not a real linter"Describe the solution you'd like.
I think we should start by improving the documentation and better explain what
typecheck
is. We should also clarify that it's not possible to disable this "linter". It may also be a good idea to remove it from the list of linters.Describe alternatives you've considered.
typecheck
is not a real linter"Additional context.
No response
Suggested troubleshooting documentation
In addition to describing what
typecheck
is and why it can't be disabled it would be useful to list some common things to try to find the root cause. Some examples would bego build ./...
- whole packagegolangci-lint
is built with a compatible version of the repo - always try latestThe text was updated successfully, but these errors were encountered: