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

Investigate if we can use GODEBUG=gotypealias=1 to get around type alias sadness #763

Open
LandonTClipp opened this issue Feb 19, 2024 · 2 comments

Comments

@LandonTClipp
Copy link
Collaborator

LandonTClipp commented Feb 19, 2024

replace-types was added because the Go AST does not have any nodes for type alias, thus the alias gets resolved to its underlying type. Go 1.22 adds a debug feature called gotypealias that seems to provide an explicit node for type aliases. This would potentially allow us to handle aliases automatically and not have it resolved to the real type.

The way to do this would be to modify .mockery.yaml to generate mocks for a type alias that points to an internal package, set GODEBUG=gotypealias=1, and see what happens. If it works then we can just update the docs to let people know.

#725 (comment)
#540 (comment)

@LandonTClipp LandonTClipp added good-first-issue Good issue for beginners or first-time contributors to tackle and removed good-first-issue Good issue for beginners or first-time contributors to tackle labels Feb 19, 2024
@LandonTClipp
Copy link
Collaborator Author

I dived into seeing if this is feasible, but it appears not. The gotypelias flag in Go 1.22 only applies to the go/types API. See initial proposal. However the compiler export data format, and importer changes, have not been completed yet. This is necessary because go/packages (which this project uses to parse the type tree) imports the compiler-exported data. So it seems we won't get go/packages support until Go 1.23 at least.

golang/go#64208

@LandonTClipp
Copy link
Collaborator Author

Some additional clarity on where this issue lies. I discovered the gopackages tool that allows you to briefly inspect the syntax of a particular package. You see that when we ask it to print one of our packages that has a type alias on an internal type, the alias is not preserved:

go run golang.org/x/tools/go/packages/gopackages -mode allsyntax github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type
Go package "github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type":
        package replace_type
        has complete exported type info and typed ASTs
        file /Users/landonclipp/git/LandonTClipp/mockery/pkg/fixtures/example_project/replace_type/rt.go
        import "github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/rt1"
        import "github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/rt2"
        type RType interface{Replace1(f github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/internal.RTInternal1); Replace2(f github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/internal.RTInternal2)}
        method (RType) Replace1(f github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/internal.RTInternal1)
        method (RType) Replace2(f github.com/vektra/mockery/v2/pkg/fixtures/example_project/replace_type/rti/internal.RTInternal2)

This is just further proof that we cannot do anything further until the Go devs update the compiler export format and importers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant