Skip to content

False positive for structcheck linter #1517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
lukasmalkmus opened this issue Nov 19, 2020 · 6 comments · Fixed by #3125
Closed
3 tasks done

False positive for structcheck linter #1517

lukasmalkmus opened this issue Nov 19, 2020 · 6 comments · Fixed by #3125
Assignees
Labels
bug Something isn't working dependencies Relates to an upstream dependency

Comments

@lukasmalkmus
Copy link

Thank you for creating the issue!

  • Yes, I'm using a binary release within 2 latest major releases. Only such installations are supported.
  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've included all information below (version, config, etc).

Please include the following information:

Version of golangci-lint
$ golangci-lint --version
golangci-lint has version 1.32.2 built from 52d26a3 on 2020-11-03T01:15:38Z
Config file
$ cat .golangci.yml
linters:
  disable-all: true
  enable:
    - structcheck
Go environment
$ go version && go env
go version go1.15.5 darwin/amd64
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/lukasmalkmus/Library/Caches/go-build"
GOENV="/Users/lukasmalkmus/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/lukasmalkmus/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/lukasmalkmus/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/opt/[email protected]/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/[email protected]/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dy/s6dd70892l35f0444cwt96t40000gn/T/go-build258997589=/tmp/go-build -gno-record-gcc-switches -fno-common"
Verbose output of running
$ golangci-lint cache clean
$ golangci-lint run -v
INFO [config_reader] Config search paths: [./ /Users/lukasmalkmus/Code/OSS/golangci-lint-unused-issue /Users/lukasmalkmus/Code/OSS /Users/lukasmalkmus/Code /Users/lukasmalkmus /Users /] 
INFO [config_reader] Used config file .golangci.yml 
INFO [lintersdb] Active 1 linters: [structcheck]  
INFO [loader] Go packages loading at mode 575 (types_sizes|deps|imports|name|compiled_files|exports_file|files) took 58.89566ms 
INFO [runner/filename_unadjuster] Pre-built 0 adjustments in 1.306913ms 
INFO [linters context/goanalysis] analyzers took 411.503µs with top 10 stages: structcheck: 411.503µs 
INFO [runner] Processors filtering stat (out/in): exclude-rules: 1/1, max_per_file_from_linter: 1/1, skip_dirs: 1/1, identifier_marker: 1/1, sort_results: 1/1, nolint: 1/1, diff: 1/1, max_same_issues: 1/1, max_from_linter: 1/1, source_code: 1/1, path_prefixer: 1/1, cgo: 1/1, filename_unadjuster: 1/1, autogenerated_exclude: 1/1, exclude: 1/1, uniq_by_line: 1/1, path_shortener: 1/1, severity-rules: 1/1, path_prettifier: 1/1, skip_files: 1/1 
INFO [runner] processing took 1.266122ms with stages: autogenerated_exclude: 847.753µs, exclude: 106.116µs, path_prettifier: 87.223µs, nolint: 86.367µs, source_code: 57.543µs, identifier_marker: 30.058µs, skip_dirs: 26.597µs, filename_unadjuster: 7.692µs, uniq_by_line: 3.782µs, max_same_issues: 3.429µs, cgo: 2.592µs, path_shortener: 1.914µs, max_from_linter: 1.446µs, max_per_file_from_linter: 796ns, diff: 559ns, exclude-rules: 553ns, skip_files: 546ns, severity-rules: 409ns, sort_results: 385ns, path_prefixer: 362ns 
INFO [runner] linters took 491.719474ms with stages: structcheck: 490.285749ms 
test.go:4:2: `b` is unused (structcheck)
        b string
        ^
INFO File cache stats: 1 entries of total size 102B 
INFO Memory: 7 samples, avg is 71.8MB, max is 71.8MB 
INFO Execution took 598.573223ms
package issue

type a struct {
	b string
}

type A a

var b = A{"b"}

func B() string {
	return b.b
}

Thies yields an error which isn't true:

test.go:4:2: `b` is unused (structcheck)
        b string
        ^

Field b is used.

@lukasmalkmus lukasmalkmus added the bug Something isn't working label Nov 19, 2020
@rkperes
Copy link

rkperes commented Dec 1, 2020

There's an open old issue for the linter: https://gitlab.com/opennota/check/-/issues/11.

As stated in their docs:

Known limitations

structcheck doesn't handle embedded structs yet.

@iwankgb iwankgb self-assigned this Dec 5, 2020
@iwankgb
Copy link
Contributor

iwankgb commented Dec 5, 2020

@lukasmalkmus, it will take a while I think. Before I fix it I will try to get rid of the fork and move golangci-lint to upstream version. I will keep updating this issue.

@iwankgb
Copy link
Contributor

iwankgb commented Dec 12, 2020

@lukasmalkmus unfortunately it does not seem to be possible to switch golangci-lint to upstream structcheck. There are too fundamental differences between the fork: we use golang.org/x/tools/go/analysis and structcheck upstream uses golang.org/x/tools/go/packages. Whole point of the for has been to rewrite whole check repo, apparently. There are no tests there so the refactoring/rewrite looks risky to me.
Merging changes from the upstream to the fork seems to be equally complicated and it looks like we have separate project to maintain nowadays. I'm not sure if this is something that we are ready to invest into. @golangci/team, @ernado - what do you think?

@iwankgb
Copy link
Contributor

iwankgb commented Dec 29, 2020

@golangci/team do we want to invest time in maintaining forks in golangci organization?

@SVilgelm
Copy link
Member

@iwankgb IMO we need to get rid of as much as possible forks and use the original projects.

@stale
Copy link

stale bot commented Mar 30, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependencies Relates to an upstream dependency
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants