commit | 4316a961ee8a5ad7c9c664adca9b26318bf14ead | [log] [tgz] |
---|---|---|
author | Hana (Hyang-Ah) Kim <hyangah@gmail.com> | Thu Nov 02 13:51:57 2023 -0400 |
committer | Gopher Robot <gobot@golang.org> | Wed Nov 29 18:53:02 2023 +0000 |
tree | 6204a90b8d93eb456fd63661e02ad9fae9208dc9 | |
parent | d8333230d2cac81aeb952a4d51e2fd2b06e0a472 [diff] |
src/language/goLanguageServer: improve suggestGoplsIssueReport The extension runs suggestGoplsIssueReport when it observes the language server client crashes. It prompts the user and collects useful information from settings, configuration, and the LSP server output channel ("gopls (server)") where stderr and LSP log messages are logged, populates a github issue template when the user agrees. This change improves the log collection and sanitization. * Incorrect version info and timestamp - previously they were computed after the user chooses "Yes" on the prompt. Usually, there is a delay between the problem occurs and the user notices the popup. Often, vscode hides the prompt window! It's possible that a new gopls or extension version was installed and restarted in between. This CL makes the suggestGoplsIssueReport accepts the configuration used when starting the crashed gopls session, and computes the issue timestamp before prompting. Moreover, we also compute the gopls version when the configuration object is built. Previously, it was lazily evaluated to avoid excessive file stats and `gopls version` process runs. In this CL, we remove unnecessary buildLanguageServerConfig calls - the latest config is cached in `goCtx.latestCfg`. One side-effect of this change is `buildLanguageServerConfig` is now async to run `gopls version`. * Gopls's crash info is in `gopls (server)` output channel. collectGoplsLog attempted to collect the data in a hacky way by iterating all open documents and picking the first one that looks like our log. Unfortunately, this doesn't work when there are multiple extensions with output channels. Fix this bug - recent versions of vscode now use file names that include the channel name, so we can pin point the right output channel doc. * The extension may trigger multiple gopls restarts back to back because there are currently multiple vantage points for checking for gopls update asynchronously. Such successive restarts may be unclean and the lsp client lib classifies them as crashes. The new session may be already up and running. This CL makes suggestGoplsIssueReport check gopls versions (what's used in the currently crashed session and what's the latest config the extension saw) and prompt only if they are same. It would be nice if we can centralize gopls install/upgrade decision making and reduce the chance of successive, unnecessary gopls restarts. But that is a major change and can be a separate project. We also learned a couple of new crash log patterns. Integrate the followings in the log scrubbing logic. * log.Fatal - "filename.go:line ...." * LSP 3.17 client library changed the initialization error log text. That explains the increased in the number of empty reports after we updated our dependency. This change also embeds `gopls stats -anon` output. That may reveal issues in the workspace setup. For a large project, gopls stats may take a while. Limit the execution to 60sec. While we are here, we also simplify the periodic gopls update check (scheduleGoplsSuggestions). That will remove another buildLanguageServerConfig call. Fixes golang/vscode-go#984 Fixes golang/vscode-go#2690 Change-Id: Ib8aa2abbd5f0c812605ced13c9c93b8aa3bb94fd Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/539415 Auto-Submit: Hyang-Ah Hana Kim <hyangah@gmail.com> Commit-Queue: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
The VS Code Go extension provides rich language support for the Go programming language.
Welcome! 👋🏻
Whether you are new to Go or an experienced Go developer, we hope this extension fits your needs and enhances your development experience.
Install Go 1.18 or newer if you haven't already.
Install the VS Code Go extension.
Open any directory or workspace containing Go code to automatically activate the extension. The Go status bar appears in the bottom left corner of the window and displays your Go version.
The extension depends on go
, gopls
, dlv
and other optional tools. If any of the dependencies are missing, the ⚠️ Analysis Tools Missing
warning is displayed. Click on the warning to download dependencies.
See the tools documentation for a complete list of tools the extension depends on.
You are ready to Go :-) 🎉🎉🎉
If you are new to Go, this article provides the overview on Go code organization and basic go
commands. Watch “Getting started with VS Code Go” for an explanation of how to build your first Go application using VS Code Go.
See the full feature breakdown for more details.
In addition to integrated editing features, the extension provides several commands for working with Go files. You can access any of these by opening the Command Palette (Ctrl+Shift+P
on Linux/Windows and Cmd+Shift+P
on Mac), and then typing in the command name. See the full list of commands provided by this extension.
⚠️ Note: the default syntax highlighting for Go files is provided by a TextMate rule embedded in VS Code, not by this extension.
For better syntax highlighting, we recommend enabling semantic highlighting by turning on Gopls' ui.semanticTokens
setting. "gopls": { "ui.semanticTokens": true }
The VS Code Go extension supports both GOPATH
and Go modules modes.
Go modules are used to manage dependencies in recent versions of Go. Modules replace the GOPATH
-based approach to specifying which source files are used in a given build, and they are the default build mode in go1.16+. We highly recommend Go development in module mode. If you are working on existing projects, please consider migrating to modules.
Unlike the traditional GOPATH
mode, module mode does not require the workspace to be located under GOPATH
nor to use a specific structure. A module is defined by a directory tree of Go source files with a go.mod
file in the tree's root directory.
Your project may involve one or more modules. If you are working with multiple modules or uncommon project layouts, you will need to configure your workspace by using Workspace Folders. See the Supported workspace layouts documentation for more information.
If you'd like to get early access to new features and bug fixes, you can use the nightly build of this extension. Learn how to install it in by reading the Go Nightly documentation.
VS Code Go extension relies on the Go Telemetry to learn insights about the performance and stability of the extension and the language server (`gopls``). Go Telemetry data uploading is disabled by default and can be enabled with the following command:
go run golang.org/x/telemetry/cmd/gotelemetry@latest on
After telemetry is enabled, the language server will upload metrics and stack traces to telemetry.go.dev. You can inspect what data is collected and can be uploaded by running:
go run golang.org/x/telemetry/cmdgotelemetry@latest view
If we get enough adoption, this data can significantly advance the pace of the Go extension development, and help us meet a higher standard of reliability. For example:
These are just a few ways that telemetry can improve gopls. The telemetry blog post series contains many more.
Go telemetry is designed to be transparent and privacy-preserving. If you have concerns about enabling telemetry, you can learn more at https://telemetry.go.dev/privacy.
We welcome your contributions and thank you for working to improve the Go development experience in VS Code. If you would like to help work on the VS Code Go extension, see our contribution guide to learn how to build and run the VS Code Go extension locally and contribute to the project.
This project follows the Go Community Code of Conduct. If you encounter a conduct-related issue, please mail conduct@golang.org.