Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: shallow export data produces non-canonical forwarded fields/methods #60819

Closed
findleyr opened this issue Jun 15, 2023 · 1 comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Contributor

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 :(

CC @adonovan @griesemer @mdempsky

@findleyr findleyr added this to the gopls/v0.13.0 milestone Jun 15, 2023
@gopherbot 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
@gopherbot
Copy link

Change https://go.dev/cl/503438 mentions this issue: internal/gcimporter: supporting encoding objects from different packages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

2 participants