Closed bluecivet closed 1 week ago
A copy of a discussion from the Wharf issue could be helpful: https://github.com/ZOSOpenTools/wharf/issues/38
The issue arises within the type checking process, specifically in the func AssignableTo(V, T Type) bool function, which fails to provide accurate type checks for Named type. . The function relies on indenticalOrigin to verify the original type. However, the problem lies in its use of the == operator to compare Name structs that include pointers. This comparison method can lead to inaccurate results as it checks memory addresses rather than the actual content of the structs. Compounding this issue is Wharf's behavior of creating a new package instance each time it filters a configuration. Consequently, pointers within Name structs may differ between package instances.
Duplicate of #64477
This is WAI. Each call to conf.Check returns a new types.Package and each type.Named within that copy of the package is considered distinct. (As for why? A lot gets pinned to memory in the implementation or speed and simplicity, and there are issues of temporal consistency.) The expectation is that if a user of go/types retype checks package, e.g. "pa/bbb", they also retype all packages that transitively import that package, e.g. "pa/main" and "pb/inner". This is what gopls does.
The documentation could be improved https://github.com/golang/go/issues/53914. There is also a proposal to change this behavior https://github.com/golang/go/issues/57497.
Go version
go1.21 linux/arm64
Output of
go env
in your module/workspace:What did you do?
I have the following project
pa/bbb/constant.go
pa/bbb/inner_linux.go
pa/bbb/inner_linux_zos.go
pa/aaa/outter.go
pb/inner/inner.go
pa/main.go
testType/main.go
What did you see happen?
Output:
What did you expect to see?
The very last few lines of the output
The variable type is the same but the compiler is complaining that they are different.
There should be no error at the last step of the Check function