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: report unnecessarily exported symbols #67573

Open
adonovan opened this issue May 22, 2024 · 3 comments
Open

x/tools/gopls: report unnecessarily exported symbols #67573

adonovan opened this issue May 22, 2024 · 3 comments
Labels
gopls Issues related to the Go language server, gopls. Refactoring Issues related to refactoring tools Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@adonovan
Copy link
Member

adonovan commented May 22, 2024

After a code reorganization, many symbols may continue to be exported even though they are no longer referenced from another package. Just as it is helpful to report dead code within an application, it would be useful to report symbols that could safely be unexported.

Gopls has all the information required to do this; we should expose it on request in the UI somehow.

(Or this could be a feature of cmd/deadcode. But cmd/deadcode could be a feature of gopls, too.)

@adonovan adonovan added this to the Backlog milestone May 22, 2024
@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 May 22, 2024
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/586781 mentions this issue: gopls/internal/golang: unexport several functions

@adonovan
Copy link
Member Author

adonovan commented May 22, 2024

We could easily add this as a code action "Show unnecessarily exported symbols" whose associated command should indicate one of two things (that don't currently exist in LSP, but should):

  • that its result is a set of generalized references; or
  • that its progress messages can be treated like a mixed stdout/stderr stream to a terminal-like viewer (e.g. VS Code output window, Emacs non-file buffer, etc). Automated linkification should suffice.

@findleyr had a neat idea: produce the report as a web page (which we could easily do today), with a list of checkboxes, one per function. The user could select a subset of them then hit an "Apply changes" button, which would cause the server to send one or more ApplyEdit downcalls to do the renamings.

gopherbot pushed a commit to golang/tools that referenced this issue May 22, 2024
All of these functions are no longer referenced across
packages since we cleaned up the server/lsprpc/golang split.

CanExtractVariable
EmbedDefinition
EnclosingStaticCall
FormatNodeFile
LinknameDefinition
CanExtractFunction

Updates golang/go#67573

Change-Id: I18490b333d79bad83eb5fcc34688fb41381771d1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/586781
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
@adonovan adonovan added the Refactoring Issues related to refactoring tools label May 22, 2024
@findleyr findleyr modified the milestones: Backlog, gopls/backlog May 23, 2024
@ian-h-chamberlain
Copy link

👍 to this feature.

As a companion feature, a code action to easily toggle exported-ness of a single symbol (or struct member) would also be helpful! That would make it easier to fix one-off instances as you see them, without needing to explicitly run the analysis for the entire package/workspace. I imagine the necessary pieces of functionality would be very similar to those needed for a report like this.

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. Refactoring Issues related to refactoring tools Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants