typecheck: Single compiler error results in 200+ identical reports

[atetubou]

Welcome

• Yes, I'm using a binary release within 2 latest releases. Only such installations are supported.
• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've read the typecheck section of the FAQ.
• Yes, I've tried with the standalone linter if available (e.g., gocritic, go vet, etc.).
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

Official binary

Description of the problem

If I removed the limit for number of issue reported and disable deduplication of issue, typecheck linter emits more than 200 warnings for the same issue.

Why typecheck linter emits exactly the same issue more than once?

Version of golangci-lint

$ golangci-lint --version
golangci-lint has version 2.1.6 built with go1.24.2 from eabc2638 on 2025-05-04T15:41:19Z

Configuration

# paste configuration file or CLI flags here
golangci-lint run --max-issues-per-linter=0 --max-same-issues=0 --uniq-by-line=false main.go

Go environment

$ go version && go env
go version go1.24.2 linux/amd64
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/usr/local/google/home/tikuta/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/usr/local/google/home/tikuta/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3237501649=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/usr/local/google/home/tikuta/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/usr/local/google/home/tikuta/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go-1.24'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/usr/local/google/home/tikuta/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go-1.24/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

Verbose output of running

$ golangci-lint cache clean
$ golangci-lint run -v
# See repro case in next section

A minimal reproducible example or link to a public repository

To reproduce, I made the following `main.go` file.

package main

import (
        "context"
)

func main() {
        context.Background(1)
}

And ran the following command

$ golangci-lint cache clean
$ golangci-lint run -v --max-issues-per-linter=0 --max-same-issues=0 --uniq-by-line=false main.go
INFO golangci-lint has version 2.1.6 built with go1.24.2 from eabc2638 on 2025-05-04T15:41:19Z
INFO [config_reader] Config search paths: [./ /usr/local/google/home/tikuta/hoge /usr/local/google/home/tikuta /usr/local/google/home /usr/local/google /usr/local /usr /]
INFO maxprocs: Leaving GOMAXPROCS=128: CPU quota undefined
INFO [goenv] Read go env for 4.970333ms: map[string]string{"GOCACHE":"/usr/local/google/home/tikuta/.cache/go-build", "GOROOT":"/usr/lib/go-1.24"}
INFO [lintersdb] Active 5 linters: [errcheck govet ineffassign staticcheck unused]
INFO [loader] Go packages loading at mode 8767 (exports_file|files|imports|name|deps|types_sizes|compiled_files) took 568.929052ms
INFO [runner/filename_unadjuster] Pre-built 0 adjustments in 189.029µs
INFO [linters_context/goanalysis] analyzers took 766.99589ms with top 10 stages: buildir: 521.883656ms, inspect: 35.689032ms, ctrlflow: 33.753834ms, printf: 33.368427ms, fact_deprecated: 33.149715ms, SA5012: 26.148735ms, fact_purity: 25.232918ms, nilness: 24.428653ms, typedness: 23.733103ms, tokenfileanalyzer: 2.051297ms
INFO [runner] Processors filtering stat (in/out): severity-rules: 201/201, path_absoluter: 201/201, exclusion_paths: 201/201, generated_file_filter: 201/201, fixer: 201/201, max_from_linter: 201/201, path_shortener: 201/201, cgo: 201/201, filename_unadjuster: 201/201, diff: 201/201, max_per_file_from_linter: 201/201, max_same_issues: 201/201, sort_results: 201
/201, invalid_issue: 201/201, exclusion_rules: 201/201, nolint_filter: 201/201, uniq_by_line: 201/201, path_prettifier: 201/201, path_relativity: 201/201, source_code: 201/201
INFO [runner] processing took 633.331µs with stages: source_code: 222.181µs, path_relativity: 167.959µs, sort_results: 104.699µs, path_shortener: 34.705µs, max_per_file_from_linter: 15.901µs, path_absoluter: 14.287µs, generated_file_filter: 13.335µs, nolint_filter: 12.895µs, cgo: 12.393µs, invalid_issue: 11.541µs, filename_unadjuster: 11.342µs, path_prettifier
: 8.266µs, max_same_issues: 1.102µs, exclusion_rules: 581ns, exclusion_paths: 581ns, fixer: 531ns, max_from_linter: 440ns, diff: 331ns, uniq_by_line: 141ns, severity-rules: 120ns
INFO [runner] linters took 837.679584ms with stages: goanalysis_metalinter: 836.957984ms
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
<snip>
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
        context.Background(1)
                           ^
201 issues:
* typecheck: 201
INFO File cache stats: 1 entries of total size 76B
INFO Memory: 16 samples, avg is 130.4MB, max is 302.8MB
INFO Execution took 1.416909003s

Validation

• Yes, I've included all information above (version, config, etc.).

Supporter

• I am a sponsor/backer through GitHub or OpenCollective

[alexandear]

@atetubou Just to clarify, typecheck is not a linter, but rather a front-end for the Go compiler. It validates that your code is syntactically and semantically correct. See https://golangci-lint.run/welcome/faq/#why-do-you-have-typecheck-errors

In your example, the following line is not valid Go:

context.Background(1)

The context.Background() function does not accept any arguments, so this call is invalid.

[atetubou]

Hi @alexandear,

Thanks for your comment. I understand that context.Background(1) is invalid Go code because context.Background() does not accept any arguments.

My apologies if my initial report was unclear. The core of this issue is not about the validity of the Go code itself, but rather about the behavior of the typecheck component within golangci-lint. Specifically, as demonstrated in the reproducible example, when options --max-issues-per-linter=0, --max-same-issues=0, and --uniq-by-line=false are set, typecheck emits the exact same warning over 200 times for this single invalid line of code.

My question is why typecheck generates the same diagnostic message multiple times for the identical piece of code, rather than just once, especially when deduplication mechanisms are explicitly disabled for testing purposes

[ldez]

Typecheck errors are not reports/issues, they cannot be filtered.

This is explained inside the documentation: https://golangci-lint.run/welcome/faq/#why-do-you-have-typecheck-errors

[atetubou]

Hi @ldez,

Thank you for your response and for pointing to the FAQ section. I understand from the documentation that typecheck errors are essentially Go compiler errors and are not linter reports, and therefore cannot be disabled or ignored because they prevent further analysis.

My question is more specifically about the duplication of these typecheck messages. As shown in the reproducible example, a single underlying Go compilation error (e.g., context.Background(1)) results in typecheck emitting over 200 identical warnings when flags like --max-issues-per-linter=0, --max-same-issues=0, and --uniq-by-line=false are used.

Could you please clarify which part of the "Why do you have typecheck errors?" section, or the "Why is it not possible to skip/ignore typecheck errors?" section, explains this behavior of emitting the same compiler error message multiple times? My concern is not about filtering these fundamental errors, but rather understanding why they are reported in such a highly duplicated manner by the typecheck front-end, even when standard deduplication mechanisms are seemingly turned off for testing.

Thank you for your time and clarification.

[ldez]

$ go build ./...       
# github.com/golangci/sandbox
./main.go:8:21: too many arguments in call to context.Background
        have (number)
        want ()

$ golangci-lint version
golangci-lint has version 2.1.6 built with go1.24.2 from eabc2638 on 2025-05-04T15:41:19Z

$ golangci-lint run    
main.go:1: : # github.com/golangci/sandbox
./main.go:8:21: too many arguments in call to context.Background
        have (number)
        want () (typecheck)
package main
1 issues:
* typecheck: 1

As you can see, based on your example, there is only one report.

[ldez]

The only element that impacts the number of errors in your context is uniq-by-line: false.

So, the behavior is expected because you will have one error per linter.

[atetubou]

Thank you for your latest comment. I understand that "uniq-by-line: false" is the key flag here, and the general expectation is "one report per linter".

My goal with --uniq-by-line=false (and other flags like --max-issues-per-linter=0 and --max-same-issues=0) was to see multiple warnings on the same line if they came from different linters.

However, the issue is that typecheck alone outputs the same compiler error over 200 times when these flags are used. This makes the output very noisy due to typecheck's behavior, not due to different linters reporting.

So, my specific question remains: why does the typecheck component (the Go compiler error front-end report the exact same compilation error numerous times, rather than just once, even when uniq-by-line is disabled? Is this multiplicative reporting by typecheck itself the intended behavior with these flags?

Thanks for helping me clarify this.

[ldez]

why does the typecheck component (the Go compiler error front-end report the exact same compilation error numerous times, rather than just once, even when uniq-by-line is disabled?

Because the linters are run inside go routine, so each enabled linter will report a typecheck error.

I will improve that.

[atetubou]

Hi @ldez,

Thank you for your latest response and for clarifying the reason behind the multiple typecheck reports: "Because the linters are run inside go routine, so each enabled linter will report a typecheck error".

Given your statement, "I will improve that", it seems there's an intention to change this behavior.

In light of this, could we please consider re-opening this issue? Since an improvement is planned, the current "completed" status might not fully reflect the situation.

Thank you!