|author||Robert Findley <firstname.lastname@example.org>||Mon May 09 12:14:36 2022 -0400|
|committer||Robert Findley <email@example.com>||Fri Sep 23 13:51:08 2022 +0000|
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 <firstname.lastname@example.org> TryBot-Result: Gopher Robot <email@example.com> Reviewed-by: Hyang-Ah Hana Kim <firstname.lastname@example.org> Run-TryBot: Robert Findley <email@example.com> Reviewed-by: Alan Donovan <firstname.lastname@example.org>
This repository provides the
golang.org/x/tools module, comprising various tools and packages mostly for static analysis of Go programs, some of which are listed below. Use the “Go reference” link above for more information about any package.
It also contains the
golang.org/x/tools/gopls module, whose root package is a language-server protocol (LSP) server for Go. An LSP server analyses the source code of a project and responds to requests from a wide range of editors such as VSCode and Vim, allowing them to support IDE-like functionality.
cmd/goimportsformats a Go program like
go fmtand additionally inserts import statements for any packages required by the file after it is edited.
cmd/callgraphprints the call graph of a Go program.
cmd/digraphis a utility for manipulating directed graphs in textual notation.
cmd/stringergenerates declarations (including a
Stringmethod) for “enum” types.
cmd/toolstashis a utility to simplify working with multiple versions of the Go toolchain.
These commands may be fetched with a command such as
go install golang.org/x/tools/cmd/goimports@latest.
go/ssa provides a static single-assignment form (SSA) intermediate representation (IR) for Go programs, similar to a typical compiler, for use by analysis tools.
go/packages provides a simple interface for loading, parsing, and type checking a complete Go program from source code.
go/analysis provides a framework for modular static analysis of Go programs.
go/callgraph provides call graphs of Go programs using a variety of algorithms with different trade-offs.
go/ast/inspector provides an optimized means of traversing a Go parse tree for use in analysis tools.
go/cfg provides a simple control-flow graph (CFG) for a Go function.
go/expect reads Go source files used as test inputs and interprets special comments within them as queries or assertions for testing.
go/gccgoexportdata read and write the binary files containing type information used by the standard and
go/types/objectpath provides a stable naming scheme for named entities (“objects”) in the
Numerous other packages provide more esoteric functionality.
This repository uses Gerrit for code changes. To learn how to submit changes, see https://golang.org/doc/contribute.html.
The main issue tracker for the tools repository is located at https://github.com/golang/go/issues. Prefix your issue with “x/tools/(your subdir):” in the subject line, so it is easy to find.
This repository uses prettier to format JS and CSS files.
The version of
prettier used is 1.18.2.
It is encouraged that all JS and CSS code be run through this before submitting a change. However, it is not a strict requirement enforced by CI.