Skip to content
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

Deprecated package imported by its own testing package is flagged #1285

Closed
SamWhited opened this issue Jun 5, 2022 · 1 comment
Closed
Labels
false-positive started Issues we've started working on

Comments

@SamWhited
Copy link

SamWhited commented Jun 5, 2022

To reproduce:

Create a package and mark it as deprecated. Now create a _test.go file for that package that uses a testing package (eg. if the original package is foo the _test.go file should be in package foo_test, not foo). Import foo from foo_test just like you'd do if you were actually writing a test that can only test the public API.

Run staticcheck ./..., it will complain that the deprecated package is imported, which makes sense because its one package importing another, but since this is a non-importable test package it doesn't make much sense that it would be reported since of course it imports the thing it's testing.

I do not have an example of this that's public, but it can be reproduced with the following files:

-- foo_test.go --
package foo_test

import (
	"testing"

	"example.net/foo"
)

func TestMe(t *testing.T) {
	foo.TestMe()
}
-- go.mod --
module example.net/foo

go 1.18
-- foo.go --
// Deprecated: this package is old.
package foo

import "fmt"

func TestMe() {
	fmt.Println("Hello")
}

Eg.

$ staticcheck .
../.cache/go-build/06/069c29de2ba9614ca95ffbcd2668d1eef763082e02302139ed99cb8f9f69b34e-d:13:4: "example.net/foo" is deprecated: this package is old.  (SA1019)
foo_test.go:6:2: "example.net/foo" is deprecated: this package is old.  (SA1019)

Version info:

$ staticcheck -debug.version
staticcheck 2022.1.2 (v0.3.2)

Compiled with Go version: devel go1.19-a131fd1313e0 20220507105606
Main module:
        honnef.co/go/[email protected] (sum: h1:ytYb4rOqyp1TSa2EPvNVwtPQJctSELKaMyLfqNP4+34=)
Dependencies:
        github.com/BurntSushi/[email protected] (sum: h1:GaI7EiDXDRfa8VshkTj7Fym7ha+y8/XxIgD2okUIjLw=)
        golang.org/x/exp/[email protected] (sum: h1:qyrTQ++p1afMkO4DPEeLGq/3oTsdlvdH4vqZUBWzUKM=)
        golang.org/x/[email protected] (sum: h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=)
        golang.org/x/[email protected] (sum: h1:id054HUawV2/6IGm2IV8KZQjqtwAOo2CYlOToYqa0d0=)
        golang.org/x/[email protected] (sum: h1:OKYpQQVE3DKSc3r3zHVzq46vq5YH7x8xpR3/k9ixmUg=)

$ go version
go version devel go1.19-a131fd1313e0 20220507105606 linux/amd64

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sam/.cache/go-build"
GOENV="/home/sam/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/sam/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sam/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/sam/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/sam/gotip/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.19-a131fd1313e0 20220507105606"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/sam/Projects/mellium/xmpp/go.mod"
GOWORK=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3280804165=/tmp/go-build -gno-record-gcc-switches"

This also triggers #1034

@SamWhited SamWhited added false-positive needs-triage Newly filed issue that needs triage labels Jun 5, 2022
@dominikh dominikh removed the needs-triage Newly filed issue that needs triage label Jun 5, 2022
@dominikh
Copy link
Owner

This is not limited to external tests but affects normal tests too, as they cause Go to generate files that import the package under test. I'm honestly not sure how more people haven't run into this issue.

@dominikh dominikh added the started Issues we've started working on label Jan 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
false-positive started Issues we've started working on
Projects
None yet
Development

No branches or pull requests

2 participants