{{ message }}
Repository navigation
Type aliases points to the underlying type not the root one, this cause issues where the autogenerated go package does not build if it links to internal packages. #348
Description
I have code like this:
.
├── a.go
├── b
│ ├── b.go
│ └── internal
│ └── internal.go
└── go.mod
// a.go
package a
import "a/b"
type A = b.B// b.go
package b
import "a/b/internal"
type B = internal.I// internal.go
package internal
import "strconv"
type I uint
func (i I) String() string { return strconv.FormatUint(uint64(i), 10) }gopy pkg a then creates a folder a/a and tries to import a/b/internal which does not work because it's not allowed to import an internal package.
My real world usecase is some existing librairy with type alias chains going through multiple modules.
I think this could be solved with the GODEBUG=gotypesalias=1 https://pkg.go.dev/go/types#Alias but I'm not familiar with the gopy codebase.
Activity
rcoreilly commentedon Apr 22, 2024
Your PR fixed this right?
rcoreilly commentedon Apr 22, 2024
also internal is now excluded automatically
Jorropo commentedon Apr 23, 2024
I retried with cdad836, it does not, my PR fixed some panic but there are more
with
GODEBUG=gotypesalias=1:Jorropo commentedon Apr 23, 2024
My particular repro: