Add types.Unlias to types assertions and types switches to get an underlying type instead of types.Alias
#33868
Conversation
…into go-type-unaliasing
…et an underlying type instead of types.Alias
…et an underlying type instead of types.Alias
…into go-type-unaliasing
|
Assigning reviewers. If you would like to opt out of this review, comment R: @lostluck for label go. Available commands:
The PR bot will only process comments in the main thread (not review comments). |
There was a problem hiding this comment.
I think the other comments are the main concerns: We don't want to generate code with underlying/aliased types, we want to use the aliased types for naming things.
There's certainly value in the cases where an alias could be made instead of the raw code. The Unalias handling would have been great when this was originally written, and would have lead to a different approach, had it existed pre generics at all.
However, as I said in my other message: There isn't a great deal of value in fixing this code: users should be migrating to the generic register package, vs trying to use this belabored code generator.
| // A single level is safe since the code we're analysing imports it, | ||
| // so we can assume the generated code can access it too. | ||
| if ot.IsAlias() { | ||
| if t, ok := ot.Type().(*types.Named); ok { | ||
| if t, ok := types.Unalias(ot.Type()).(*types.Named); ok { |
There was a problem hiding this comment.
I'm a bit concerned with this particular type extraction, as it will unalias an arbitrary number of alias layers, and as listed, does run the risk of crossing an internal package boundary.
| // Here's where we ensure we register new imports. | ||
| if t, ok := t.(*types.Named); ok { | ||
| if t, ok := types.Unalias(t).(*types.Named); ok { |
There was a problem hiding this comment.
This one also feels risky WRT deriving the right import afterwards, where we'd want to have the alias' package.
It's a bit compounded with the unaliases from the extractFromContainer call too.
| func (e *Extractor) deref(v *types.Var) string { | ||
| p := v.Type().(*types.Pointer) | ||
| p := types.Unalias(v.Type()).(*types.Pointer) | ||
| return types.TypeString(p.Elem(), e.qualifier) | ||
| } |
There was a problem hiding this comment.
I think this change is unnecessary and will break things since it's already expecting a pointer to a value and is trying to get the name of the pointer type anyway.
Given types like this:
type A = someType
var a *A
should still produce "A" for this case.
| @@ -749,7 +749,7 @@ func (e *Extractor) varString(v *types.Var) string { | |||
| // NameType turns a reflect.Type into a string based on it's name. | |||
| // It prefixes Emit or Iter if the function satisfies the constrains of those types. | |||
| func (e *Extractor) NameType(t types.Type) string { | |||
| switch a := t.(type) { | |||
| switch a := types.Unalias(t).(type) { | |||
There was a problem hiding this comment.
This one doesn't need to change, since the default case already handled Aliases as desired AFAICT https://cs.opensource.google/go/go/+/refs/tags/go1.23.6:src/go/types/typestring.go;l=340
Go 1.24's types package changes type representation: types created as aliases would be represented by
types.Aliasinstead of its underlying type as before. This requires updates to any code using go/types. Specifically, types.Unalias(t) may be needed before type assertions/switches to handle aliases.Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, commentfixes #<ISSUE NUMBER>instead.CHANGES.mdwith noteworthy changes.See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)
See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.