Differentiate between errors and warnings in VSCode

[natefinch]

Your feature request related to a problem? Please describe.

I can set the severity in golangci-lint's config to error or warning and vscode displays the linting the same way, seemingly as a warning.

I'd like to be able to separate out style suggestions from linting errors that indicate bugs... which is what severity is for, but I'm not sure it's getting output in the right format for vscode to understand.

Describe the solution you'd like.

I believe there's a way to format the output so that vscode can differentiate between errors and warnings.

Describe alternatives you've considered.

I don't know that there is an alternative.

Additional context.

No response

[butuzov]

I love this topic, but always find excuses to procrastinate my research on it.

So here are a few things about severity:

• It's supported by multiple linters (e.g. revive) on its own. golangci-lint does not respect that concept (because it's hard to respect it tbh). Linter severity will be overwritten by default severity of golangci-lint
• We can define useless severities, with severity settings. Why is useless? exit-code is 1 on errors, but can be changed via --issues-exit-code. so no real exit-code: 0 if everything is warning or info.

This is what we have in severity comment:

  # Default value is empty string.
  # Set the default severity for issues. If severity rules are defined and the issues
  # do not match or no severity is provided to the rule this will be the default
  # severity applied. Severities should match the supported severity names of the
  # selected out format.
  # - Code climate: https://docs.codeclimate.com/docs/issues#issue-severity
  # -   Checkstyle: https://checkstyle.sourceforge.io/property_types.html#severity
  # -       Github: https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-error

now let's play with a code? (everybody like examples)?

.golangci..yaml

linters:
  disable-all: true

  enable:
  - revive
  - lll
  - makezero
  - dogsled

# all available settings of specific linters
linters-settings:

  dogsled:
    max-blank-identifiers: 1

  makezero:
    always: true

  lll:
    line-length: 40

  revive:
    ignore-generated-header: true
    confidence: 0.5
    severity: warning
    rules:
    - name: atomic
      severity: info

severity:
  default-severity: error
  case-sensitive: false

  rules:
  - linters:
    - lll
    severity: info

  - linters:
    - dogsled
    severity: error

  - linters:
    - makezero
    severity: warn

package main

import (
	"fmt"
	"os"
	"sync/atomic"
)

func main() {
	_, _ = fmt.Fprintln(os.Stdout, "ping")

	// looooooooooooooooooooooooooooooooooooooooooooooooooooo

	_ = make([]int, 10)

	x := uint64(1)
	_, x = 10, atomic.AddUint64(&x, 1)
}

if you run this with

golangci-lint run --out-format json | jq  '.Issues[] | {text: .Text, severity: .Severity }'

you will get something like

{
  "text": "declaration has 2 blank identifiers",
  "severity": "error"
}
{
  "text": "line is 58 characters",
  "severity": "info"
}
{
  "text": "slice `_` does not have non-zero initial length",
  "severity": "warn"
}
{
  "text": "atomic: direct assignment to atomic value",
  "severity": "error"
}

So how does vscode-go consume linter warnings? this is how

https://github.com/golang/vscode-go/blob/4cb78f6eae0307155300d63ce6b4547c6241927a/src/goLint.ts#L107-L125

Let's read this together:

1. if no run command, add it to the beginning.
2. if no --print-issued-lines=false we add this, so no issue lines are printed.
3. explicitly print in --out-format=colored-line-number format.
4. if not provided --issues-exit-code= it adds --issues-exit-code=0

So.. This is how vscode-go see changes.

I think we need to go to vscode-go team in order to find a solution for this issue together.

P.S.
I did something like this in past but nobody seems interested.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[natefinch]

This article indicates VSCode already supports linter error levels:

Take this screenshot for example, the linter found a couple of issues in the code snippet. The ones with red underlines are errors while the ones with yellow underlines are warnings.