golangci/golangci-lint · warning

can't parse line number %q: %w

Error message

can't parse line number %q: %w

What it means

When golangci-lint parses compiler error output to attach positions to issues (pkgerrors), parseErrorPosition splits a 'file:line:col' string and converts the line field with strconv.Atoi. If the line segment isn't an integer it wraps the Atoi error with the offending value via %w.

Source

Thrown at pkg/goanalysis/pkgerrors/parse.go:38

	return &result.Issue{
		Pos:        *pos,
		Text:       srcErr.Msg,
		FromLinter: "typecheck",
	}, nil
}

func parseErrorPosition(pos string) (*token.Position, error) {
	// file:line(<optional>:column)
	parts := strings.Split(pos, ":")
	if len(parts) == 1 {
		return nil, errors.New("no colons")
	}

	file := parts[0]
	line, err := strconv.Atoi(parts[1])
	if err != nil {
		return nil, fmt.Errorf("can't parse line number %q: %w", parts[1], err)
	}

	var column int
	if len(parts) == 3 { // got column
		column, err = strconv.Atoi(parts[2])
		if err != nil {
			return nil, fmt.Errorf("failed to parse column from %q: %w", parts[2], err)
		}
	}

	return &token.Position{
		Filename: file,
		Line:     line,
		Column:   column,
	}, nil
}

View on GitHub (pinned to ed7a235d2d)

Solutions

  1. Check the raw error string being parsed; identify the line that does not match file:line[:col] format
  2. Fix or filter the producer of malformed output so it emits standard go/compiler positions
  3. Upgrade golangci-lint / the analyzer emitting non-standard output
  4. If parsing your own output, verify with regexp `^(.+):(\d+)(?::(\d+))?:` before calling the parser

Example fix

// before - malformed line fed to parser
"foo.go:1a: error text"
// after - standard position format
"foo.go:1:10: error text"
Defensive patterns

Strategy: validation

Validate before calling

var posRe = regexp.MustCompile(`^[^:]+:\d+:\d+:`)
// ensure third field is numeric before parsing

Try / catch

if pos, err := parseErrorPosition(s); err != nil {
    log.Printf("dropping malformed diagnostic %q: %v", s, err)
}

Prevention

When it happens

Trigger: extractErrors/parseError feed a string whose second colon-separated field is not numeric, e.g. output like 'file.go:xyz:5: message' or a position line with extra/missing segments so parts[1] is not a number.

Common situations: Non-Go tool output mixed into error streams; compiler messages in an unexpected locale/format; malformed lines from cgo or custom analyzers that don't follow the file:line:col convention.

Related errors


AI-assisted analysis of golangci/golangci-lint@ed7a235d2d (2026-09-02). Data as JSON: /api/errors/00bc3af852954b4f. Report an issue: GitHub.