Here's an annoying problem. Say you have this:
type Result struct {
Value int
}
func getValue() (string, error) {
return "ok", nil
}
func doStuff() (Result, error) {
foo, err := getValue()
if err != nil {
return nil, err
}
return &Result{
Value: foo, // Obviously invalid, since foo is a string
}, nil
}If you run gometalinter with all linters enabled, this will get a bunch of errors/warnings.
cannot use foo (type string) as type int in field valueineffectual assignment to foo (ineffassign)error return value not checked (foo declared but not used) (errcheck)error return value not checked (cannot use foo (variable of type string) as int value in struct literal) (errcheck)
It's possible to get even more false positives — for example, if you call a function that ends up not being called because of the build error error, that will trigger the deadcode linter.
The only real error here is this one:
cannot use foo (type string) as type int in field value
Dropping these linter errors into the mix serves to obscure the real error; I use "jump to next marker" to find the next error to fix, but since they're intermingled, it's initially hard to see what to fix, especially when there are multiple errors on the same line (which is true in the above example).
VSCode underlines build errors with a red squiggle, as opposed to green for linter errors, but I have also seen cases where there are only linter errors. Here's one:
That's an actual build error, but it only has a green squiggle (latest vscode-go, 1.7.1).
My proposal is to build first, and don't run any linters if there are build errors. This will also speed up responsiveness to actual syntax errors, since only a build is needed initially. (It might be good to make this an optional setting, though.)
Here's an annoying problem. Say you have this:
If you run
gometalinterwith all linters enabled, this will get a bunch of errors/warnings.cannot use foo (type string) as type int in field valueineffectual assignment to foo (ineffassign)error return value not checked (foo declared but not used) (errcheck)error return value not checked (cannot use foo (variable of type string) as int value in struct literal) (errcheck)It's possible to get even more false positives — for example, if you call a function that ends up not being called because of the build error error, that will trigger the
deadcodelinter.The only real error here is this one:
Dropping these linter errors into the mix serves to obscure the real error; I use "jump to next marker" to find the next error to fix, but since they're intermingled, it's initially hard to see what to fix, especially when there are multiple errors on the same line (which is true in the above example).
VSCode underlines build errors with a red squiggle, as opposed to green for linter errors, but I have also seen cases where there are only linter errors. Here's one:
That's an actual build error, but it only has a green squiggle (latest vscode-go, 1.7.1).
My proposal is to build first, and don't run any linters if there are build errors. This will also speed up responsiveness to actual syntax errors, since only a build is needed initially. (It might be good to make this an optional setting, though.)