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: replace/mitigate objectpath workaround for struct fields #61674

Open
findleyr opened this issue Jul 31, 2023 · 1 comment
Open
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

CL 503438 added a workaround for de-duplicating struct fields created from export data. Unfortunately, #61670 highlighted that this workaround is insufficient. At the very least, the following is an example of where the objectpath algorithm is insufficient to prevent de-duplication, when the field is forwarded from an instantiated type. There is no path to the synthetic field:

// package a
type A[P any] struct{ F P }

// package b
type B[P any] a.A[int]

Therefore, we simply can't rely on this algorithm to prevent de-duplication. We should either remove it entirely, or leave it in merely as a memory optimization. But our algorithms for references/renaming cannot depend on it.

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

Change https://go.dev/cl/514575 mentions this issue: internal/gcimporter: remove bug report on objectpath failure

gopherbot pushed a commit to golang/tools that referenced this issue Aug 2, 2023
As reported in golang/go#61674, there are certain cases involving
instantiated fields that simply can't be encoded using objectpaths.
Therefore, the workaround is fundamentally insufficient, and should
probably be removed or made irrelevant (golang/go#61674). In the
meantime, update commentary and remove the bug report.

Update the gopls regression test for this behavior to exercise the
objectpath failure. While at it, ensure that the marker regtests panic
on bugs, like all other regtests. This ran into an existing imprecise
bug report, which is amended.

Updates golang/go#61674

Change-Id: I0eaea00d46cec88ac4c20cebdde805a7db3a33ad
Reviewed-on: https://go-review.googlesource.com/c/tools/+/514575
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@findleyr findleyr modified the milestones: gopls/v0.14.0, gopls/v0.15.0 Oct 9, 2023
@findleyr findleyr modified the milestones: gopls/v0.15.0, gopls/v0.16.0 Dec 12, 2023
@findleyr findleyr modified the milestones: gopls/v0.16.0, gopls/v0.17.0 Mar 13, 2024
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