x/tools/gopls: rename: handle methods properly in new implementation #58461
Labels
Milestone
Comments
gopherbot
added
Tools
|
Change https://go.dev/cl/464902 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Feb 14, 2023
This change is a reimplementation of the renaming operation so that it no longer mixes types.Objects from different packages. The basic approach is as follows. First, the referenced object is found and classified. If it is nonexported (e.g. lowercase, or inherently local such as an import or label, or within a function body), the operation is local to that package and is carried out essentially as before. However, if it is exported, then the scope of the global search is deduced (direct for package-level var/func/const/type, transitive for fields and methods). The object is converted to an objectpath, and all the reverse dependencies are analyzed, using the objectpath to identify the target in each package. The renameObject function (the entry point for the fiddly renamer algorithm) is now called once per package, and the results of all calls are combined. Because we process variants, duplicate edits are likely. We sort and de-dup at the very end under the assumption that edits are well behaved. The "seen edit" tracking in package renaming is no longer needed. Also: - Package.importMap maps PackagePath to Package for all dependencies, so that we can resolve targets identified by (PackagePath, objectpath) to their objects in a different types.Importer "realm". It is materialized as a DAG of k/v pairs and exposed as Package.DependencyTypes. - The rename_check algorithm (renamer) is now applied once to each package instead of once to all packages. - The set of references to update is derived from types.Info, not the references operation. Still to do in follow-ups: - Method renaming needs to expand the set of renamed types (based on 'satisfy') and recompute the dependencies of their declarations, until a fixed point is reached. (Not supporting this case is a functional regression since v0.11.0, but we plan to submit this change to unblock foundational progress and then fix it before the next release. See golang/go#58461) - Lots of generics cases to consider (see golang/go#58462). - Lots more tests required. For golang/go#57987. Change-Id: I5fd8538ab35d61744d765d8bd101cd4efa41bd33 Reviewed-on: https://go-review.googlesource.com/c/tools/+/464902 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In our work to incrementalize type checking, we intentionally regressed on our support for method renaming in order to unblock progress. Specifically, when we rename an interface method and discover a concrete method that also needs renaming, we need to not just add the concrete method to the set of target objects but also include all of the reverse dependencies of that concrete method in the set of target packages. This process of dynamic programming the cross product of objects and packages must be iterated until it reaches a fixed point.
We need to fix this before v0.12.0.
The text was updated successfully, but these errors were encountered: