-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
internal/lsp/source: derive document symbols from syntax alone
The documentSymbols handler joined syntax information with type information, meaning that it was only able to satisfy requests for files in valid workspace packages. However, the value added by type information was limited, and in many cases could be derived from syntax alone. For example, while generating symbols for a const declaration, we don't need the type checker to tell us that the symbol kind is const. Refactor the documentSymbols handler to derive symbols from syntax alone. This leads to some simplifications from the code, in addition to eliminating the dependency on package data. Also, simplify symbol details to just use types.ExprString, which includes some missing information such as function return values. Also, update handling to support Go 1.18 type embedding in interfaces. Notably, this reverts decisions like golang/go#31202, in which we went to effort to make the symbol kind more accurate. In my opinion (and the opinion expressed in golang/go#52797), the cost of requiring type information is not worth the minor improvement in accuracy of the symbol kind, which (as far as I know) is only used for UI elements. To facilitate testing (and start to clean up the test framework), make several simplifications / improvements to the marker tests: - simplify the collection of symbol data - eliminate unused marks - just use cmp.Diff for comparing results - allow for arbitrary nesting of symbols. - remove unnecessary @symbol annotations from workspace_symbol tests -- their data is not used by workspace_symbol handlers - remove Symbol and WorkspaceSymbol handlers from source_test.go. On inspection, these handlers were redundant with lsp_test.go. Notably, the collection and assembly of @symbol annotations is still way too complicated. It would be much simpler to just have a single golden file summarizing the entire output, rather than weaving it together from annotations. However, I realized this too late, and so it will have to wait for a separate CL. Fixes golang/go#52797 Fixes golang/vscode-go#2242 Updates golang/go#54845 Change-Id: I3a2c2d39f59f9d045a6cedf8023ff0c80a69d974 Reviewed-on: https://go-review.googlesource.com/c/tools/+/405254 gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
- Loading branch information
Showing
24 changed files
with
403 additions
and
403 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.