You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Discovered by way of #60676, our shallow importer loses the canonical identity of forwarded fields:
package foo
type Foo struct { F int }
---
package bar
type Bar Foo
---
package baz
var _ = Bar{ F: 2 }
In this example, when we import bar.Bar, we build its underlying. However, since we have not imported foo in the same importer, we do not get the same exact type for struct { F int }, because it doesn't exist in the type index. Therefore, the importer creates a new field.
I believe this is only a problem for forwarded fields and forwarded interface methods. It is not a problem for concrete methods or embedded interfaces.
I am going to make a quick-and-dirty fix for references (using position in our objectPath algorithm 😵 ...), but we really want to avoid duplication of these objects.
A longer term solution could be:
keep track of the current decl when exporting
when exporting a field or interface method whose package differs from the current decl's package, instead of encoding the field itself, encode its package and objectpath
in the importer, use objectpath.Object to look up the corresponding canonical field
Unfortunately, this doesn't work for instantiated fields:
type Bar Foo[int]
In this case, there's nothing we can do to create a correct field. We'd want to set its origin, but there is no types.Var.SetOrigin method (or constructor), and no way to know which instance produced a given field :(
gopherbot
added
Tools
This label describes issues relating to any tools in the x/tools repository.
gopls
Issues related to the Go language server, gopls.
labels
Jun 15, 2023
Discovered by way of #60676, our shallow importer loses the canonical identity of forwarded fields:
In this example, when we import
bar.Bar
, we build its underlying. However, since we have not importedfoo
in the same importer, we do not get the same exact type forstruct { F int }
, because it doesn't exist in the type index. Therefore, the importer creates a new field.I believe this is only a problem for forwarded fields and forwarded interface methods. It is not a problem for concrete methods or embedded interfaces.
I am going to make a quick-and-dirty fix for references (using position in our objectPath algorithm 😵 ...), but we really want to avoid duplication of these objects.
A longer term solution could be:
Unfortunately, this doesn't work for instantiated fields:
In this case, there's nothing we can do to create a correct field. We'd want to set its origin, but there is no
types.Var.SetOrigin
method (or constructor), and no way to know which instance produced a given field :(CC @adonovan @griesemer @mdempsky
The text was updated successfully, but these errors were encountered: