cmd/go:在更新到1.22版本后,覆盖率文件中出现了重复的行,

0kjbasz6  于 10个月前  发布在  Go
关注(0)|答案(4)|浏览(95)

Go版本

go版本:go1.22.0 windows/amd64

在你的模块/工作区中go env的输出:

  1. GO111MODULE=on
  2. GOARCH=amd64
  3. GOBIN=
  4. GOCACHE=C:\Users\astoffels\AppData\Local\go-build
  5. GOENV=C:\Users\astoffels\AppData\Roaming\go\env
  6. GOEXE=.exe
  7. GOEXPERIMENT=
  8. GOFLAGS=
  9. GOHOSTARCH=amd64
  10. GOHOSTOS=windows
  11. GOINSECURE=
  12. GOMODCACHE=C:\Source\golang\pkg\mod
  13. GONOPROXY=
  14. GONOSUMDB=
  15. GOOS=windows
  16. GOPATH=C:\Source\golang
  17. GOPRIVATE=
  18. GOPROXY=https://proxy.golang.org,direct
  19. GOROOT=C:/Program Files/Go
  20. GOSUMDB=sum.golang.org
  21. GOTMPDIR=
  22. GOTOOLCHAIN=auto
  23. GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
  24. GOVCS=
  25. GOVERSION=go1.22.0
  26. GCCGO=gccgo
  27. GOAMD64=v1
  28. AR=ar
  29. CC=gcc
  30. CXX=g++
  31. CGO_ENABLED=0
  32. GOMOD=C:\Source\golang\src\coverageRepro\go.mod
  33. GOWORK=
  34. CGO_CFLAGS=-O2 -g
  35. CGO_CPPFLAGS=
  36. CGO_CXXFLAGS=-O2 -g
  37. CGO_FFLAGS=-O2 -g
  38. CGO_LDFLAGS=-O2 -g
  39. PKG_CONFIG=pkg-config
  40. GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\ASTOFF~1\AppData\Local\Temp\go-build2371241097=/tmp/go-build -gno-record-gcc-switches

你做了什么?

克隆了https://github.com/alainstoffels/coverageRepro
在仓库的根目录下运行:go test -cover -coverpkg=./... -coverprofile=coverage.out ./...

你看到了什么发生?

coverage.out现在包含了2行关于coverageRepro/bar/bar.go的内容。一行表示它没有被覆盖,另一行表示它被覆盖了:

  1. mode: set
  2. coverageRepro/bar/bar.go:3.12,5.2 1 0
  3. coverageRepro/bar/bar.go:3.12,5.2 1 1
  4. coverageRepro/foo/foo.go:5.12,7.2 1 1

foo.Foo()调用了bar.Bar(),所以foo.TestFoo()应该覆盖bar.Bar()

你期望看到什么?

我期望它为coverageRepro/bar/bar.go输出一行,表示它被覆盖了,就像在1.22更新之前一样:

  1. mode: set
  2. coverageRepro/bar/bar.go:3.12,5.2 1 1
  3. coverageRepro/foo/foo.go:5.12,7.2 1 1
41zrol4v

41zrol4v1#

In our codebase, this has caused our coverage file to increase from 260 MB to 1.53 GB.
Also, it's likely that this is related to #65570

xfyts7mz

xfyts7mz2#

GOEXPERIMENT=nocoverageredesign go test -cover -coverpkg=./... -coverprofile=coverage.out ./...是否解决了这个问题?如果是,那么它也与覆盖范围的重新设计(这似乎很有可能)有关。

qyzbxkaa

qyzbxkaa3#

GOEXPERIMENT=nocoverageredesign go test -cover -coverpkg=./... -coverprofile=coverage.out ./...是否解决了这个问题?如果是,那么它也与覆盖范围的重新设计(这似乎很有可能)有关。
这确实解决了问题。

js5cn81o

js5cn81o4#

从我所看到的,这种行为在覆盖重新设计工作之前就已经存在了(我在Go 1.19中看到了它)。
这里有一个例子:

  1. $ go version
  2. go version go1.19.13 linux/amd64
  3. $ go test -short -coverprofile=/tmp/c.p -coverpkg=bytes,archive/tar bytes archive/tar
  4. ok bytes 0.097s coverage: 40.4% of statements in bytes, archive/tar
  5. ok archive/tar 0.122s coverage: 57.2% of statements in bytes, archive/tar
  6. $ fgrep buffer.go:77 /tmp/c.p
  7. bytes/buffer.go:77.28,77.49 1 1
  8. bytes/buffer.go:77.28,77.49 1 0
  9. $

在没有进行覆盖重新设计的情况下,顶部也有类似的行为:

  1. $ go version
  2. go version devel go1.23-39ec246e73 Tue Feb 6 22:21:42 2024 +0000 linux/amd64
  3. $ rm -f /tmp/c.p
  4. $ GOEXPERIMENT=nocoverageredesign go test -short -coverprofile=/tmp/c.p -coverpkg=bytes,archive/tar bytes archive/tar
  5. ok bytes 0.108s coverage: 40.3% of statements in bytes, archive/tar
  6. ok archive/tar 0.095s coverage: 56.7% of statements in bytes, archive/tar
  7. $ fgrep buffer.go:66 /tmp/c.p
  8. bytes/buffer.go:66.34,67.14 1 0
  9. bytes/buffer.go:66.34,67.14 1 1
  10. $
展开查看全部

相关问题