Closed spencercornish-wk closed 1 month ago
Clarification for workaround (2) above:
mockery
binary as usualGODEBUG=gotypesalias=0 $(MOCKERY)
I believe gotypealias
being enabled would help solve some outstanding problems, like with mockery incorrectly following a type alias back to its underlying type (which is the reason replace-types
exists).
I would be of the opinion that we just fix mockery to support this and check to see how it behaves now with aliases, particularly in the test cases that exercise replace-types. Like, can we just completely disregard replace-types now? That would be cool.
This is a high priority bug to fix. I'll solicit takers for this one. If not, maybe I can get to it in a few weeks.
I believe gotypealias being enabled would help solve some outstanding problems, like with mockery incorrectly following a type alias back to its underlying type (which is the reason replace-types exists).
I think this was made exactly to fix the replace-types
problem, with this, it would be possible to remove replace-types (once Go 1.23 is the last supported version.
I'll see if I can find some time to look at it this week.
Another quick temporary fix is adding this to a Go 1.23 go.mod
file:
godebug (
gotypesalias=0
)
Created fix PR.
Thanks for the fix! Confirmed it's working https://github.com/jaegertracing/jaeger/pull/6025 without gotypesalias=0
Description
In the latest version of go, a change was made to the generation of Alias types. From the release notes:
This means that the latest version of Mockery fails to generate mocks which include alias types in the interface.
Mockery Version
Latest at time of writing (v2.44.1)
Go Version
Latest at time of writing (v1.23.0)
Installation Method
Steps to Reproduce
Minimum-reproducible code:
.mockery/yml:
Expected Behavior
Mocks to generate
Actual Behavior
This panic + stacktrace:
Temporary Workarounds
fs.DirEntry
works fineGODEBUG
gotypesalias
flag back to 0