Go: add tests for dataflow relating to type aliasing #17400
Conversation
| @@ -0,0 +1,3 @@ | |||
| module test.com/basename | |||
|
|
|||
| go 1.22.5 | |||
There was a problem hiding this comment.
Any difference if this is go 1.23.1?
| // Note trickery with packages is necessary so that Go will assign the fields the same name as well as the same type. | ||
|
|
||
| type EmbedsPkg1IntStruct = struct{ pkg1.IntStruct } | ||
| type EmbedsPkg2IntStruct = struct{ pkg2.IntStruct } |
There was a problem hiding this comment.
I think this part probably warrants a bit more explanation. What would happen without the package trickery? The comment implies that they will have different names and different types, but it's not immediately clear why that is or how it affects the test.
There was a problem hiding this comment.
This seems like a very artificial test, since I'm not sure why a package would define an alias without changing the name (just to avoid mentioning the original package?). More likely might be two packages with aliases with the same name for the same type. Would that test the same thing? Or be a separate test worth adding?
| // Tests that dataflow and interface implementation behave as expected when an interface | ||
| // is implemented using a non-equal but identical type, i.e. an equal type after alias resolution. |
There was a problem hiding this comment.
"Non-equal but identical" is a contradiction. Can we be more specific about the kinds of equality? Or perhaps we can get around the issue entirely with e.g.:
| // Tests that dataflow and interface implementation behave as expected when an interface | |
| // is implemented using a non-equal but identical type, i.e. an equal type after alias resolution. | |
| // Tests that dataflow and interface implementation behave as expected when an interface | |
| // is implemented using different type names, which resolve to the same underlying type. |
|
This should be retargeted to main, I think. |
No description provided.