error when running tests with coverage in dependant project "cover: inconsistent NumStmt: changed from 1 to 2"

[Crocmagnon]

When running tests with coverage on a project depending on gojq, I get the following error:

cover: inconsistent NumStmt: changed from 1 to 2

Reproduction with gojq directly:

$ git clone git@github.com:itchyny/gojq.git
Clonage dans 'gojq'...
remote: Enumerating objects: 7971, done.
remote: Counting objects: 100% (1484/1484), done.
remote: Compressing objects: 100% (306/306), done.
remote: Total 7971 (delta 1334), reused 1214 (delta 1174), pack-reused 6487 (from 4)
Réception d'objets: 100% (7971/7971), 1.83 Mio | 4.34 Mio/s, fait.
Résolution des deltas: 100% (5710/5710), fait.

$ cd gojq/

$ go test ./...
go: downloading go1.24.0 (linux/amd64)
go: downloading github.com/mattn/go-runewidth v0.0.15
go: downloading github.com/itchyny/go-yaml v0.0.0-20251001235044-fca9a0999f15
go: downloading github.com/google/go-cmp v0.5.4
ok      github.com/itchyny/gojq 0.736s
ok      github.com/itchyny/gojq/cli     2.880s
?       github.com/itchyny/gojq/cmd/gojq        [no test files]

$ go test -coverprofile=cover.profile ./...
ok      github.com/itchyny/gojq 0.671s  coverage: 52.6% of statements
ok      github.com/itchyny/gojq/cli     3.056s  coverage: 92.0% of statements
        github.com/itchyny/gojq/cmd/gojq                coverage: 0.0% of statements

$ go tool cover -html cover.profile
cover: inconsistent NumStmt: changed from 1 to 2

I found golang/go#45361, apparently there's an issue with goyacc and a workaround.
Would it be possible to release a new version of gojq with the workaround implemented?

[itchyny]

I know this issue since started using goyacc, but I still think go tool cover should be fixed. I don't like a workaround for this.

[Crocmagnon]

Thank you for your quick reply ☺️

I understand this point of view, I also feel like this is the right way to fix the issue 👍🏻

If it may help feed your reflection, I’d like to offer another angle: I’m in an enterprise context, where teams often have common processes in place, including test coverage. If we want to use gojq, we need it to be compatible with our tooling.
Right now, I need to replace gojq with my fork, which works but is less than ideal for lots of reasons - I don’t want to maintain a fork "just" for this.
I also understand that I’m not entitled to anything, you make the call in the end.

I feel like the proposed workaround is not that complex and easily reversible once the underlying issue is fixed.
It also doesn’t seem to bring downsides. I’m not familiar with goyacc so I may totally miss something here.

[itchyny]

Patching goyacc seems to fix the issue; golang/go#45361 (comment).

[Crocmagnon]

Your proposed patch seem to be equivalent to running goyacc with -l, isn’t it?

[itchyny]

No, it's not.