|author||Hana <email@example.com>||Thu Oct 29 19:12:37 2020 -0400|
|committer||Hyang-Ah Hana Kim <firstname.lastname@example.org>||Tue Nov 10 15:06:40 2020 +0000|
test/gopls: change test environment setup to use single file edit When we wrote the first gopls integration test, gopls required vscode to open the workspace folder while vscode code does not support dynamic workspace folder registration in test mode. As a result, we ended up having a fixed workspace folder as a test fixture, starting the test code instance with the folder, and copying necessary files to the folder. There were so many moving parts and this created race conditions and caused slow test run. Since v0.4.x, gopls starts to support single file edit and automatically constructs an internal workspace by walking the directory tree around the open file. This CL utilizes this new capability. In each suite, we start testing by starting a new gopls, opening a single file, and waiting for the gopls to finish the initial package loading. This CL introduces Env.onPatternInTrace, which watches the fake trace output channel, and emits an event when a registered pattern is observed. This is a hack to wait for the gopls's internal state to reach to a desirable state - ideally, we want to intercept all the progress report messages like gopls' regression tests once it is supported from the language client middleware. https://github.com/microsoft/vscode-languageserver-node/issues/671 We also identified subtle issues in the existing test setup. Issue 1: when the code for testing starts (using `vscode-test`'s `runTests`) we pass the extension development path. It seems like the vscode instance uses the `main` program specified in `package.json` and activates it even without us asking. As a result, when we run tests and call 'activate' again, multiple hover/completion providers are registered, and vscode returns results from legacy and gopls-based providers. For example, the completion middleware test was observing entries from gopls, and goCompletionItemProvider that uses gocode. We address this issue here by introducing the VSCODE_GO_IN_TEST environment variable. If it is set, activate will return immediately. So, tests can control when to register what, and how. We need this setting in both `launch.json` and `runTest.ts` that's invoked in CI (`npm run test`) Issue 2: when the code for testing needs to call `activate`, we got the extension instance by using `vscode.extensions.getExtension` and called its `activate`. This was because there is no easy way to supply sufficiently complete vscode's ExtensionContext. It turned out, the extension instance vscode.extensions.getExtension returns is the one built with the `main` program specified in our `package.json` - that is the webpack'ed one in `dist/goMain.js`. On the other hand, our debugging depends on pre-webpack versions in `out/*`. This caused confusion and made debugging near impossible (breakpoints we set on pre-webpack versions will not be hit because we are running a different version of extension)! We don't know if there is a way to teach `vscode-test` to use pre-webpack version. Maybe this is our misconfiguration in our launch.json and package.json. For now, we work around this issue by not calling `activate`. Instead, in this gopls test, we call `buildLanguageClient` directly. This required some refactoring work in goLanguageServer.ts. Issue 3: sinon is cool, but stubbing vscode API for channel creation is too much. While we refactor buildLanguageClient, we made changes to let the caller supply the output channels. Issue 4: as `vscode-test` starts the test vscode instance, it also activates the registered snippets and it interferes with our gopls completion middleware tests. In test, now we explicitly filter out the snippet entries. Issue 5: for some reason, the first entry in the completion middleware test that expects 'Print' item, the filter text is not set. It can be a bug, or working as intended (the first item has label === filterText). Gopls is providing the expected entry. Workaround this issue by inspecting the label field too. Updates golang/vscode-go#655 Updates golang/vscode-go#832 Change-Id: Ic7088fd551329d1c8f78078ccb24a5f529eec72a Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/266418 Run-TryBot: Hyang-Ah Hana Kim <email@example.com> TryBot-Result: kokoro <firstname.lastname@example.org> Trust: Hyang-Ah Hana Kim <email@example.com> Trust: Suzy Mueller <firstname.lastname@example.org> Reviewed-by: Suzy Mueller <email@example.com> Reviewed-by: Rebecca Stambler <firstname.lastname@example.org>
This extension provides rich language support for the Go programming language in VS Code.
Take a look at the Changelog to learn about new features.
Welcome! Whether you are new to Go or an experienced Go developer, we hope this extension will fit your needs and enhance your development experience.
Before you start coding, make sure that you have already installed Go, as explained in the Go installation guide.
If you are unsure whether you have installed Go, open the Command Palette in VS Code (Ctrl+Shift+P) and run the
Go: Locate Configured Go Tools command. If the
GOROOT output is empty, you are missing a Go installation. For help installing Go, ask a question on the
#newbies Gophers Slack channel.
Read about Go code organization to learn how to configure your environment. This extension works in both GOPATH and module modes. We suggest using modules, as they are quickly becoming the new standard in the Go community.
Here are some additional resources for learning about how to set up your Go project:
NOTE: If you are using modules, we recommend using the Go language server, which is explained below.
More advanced users may be interested in using different
GOPATHs or Go versions per-project. You can learn about the different
GOPATH manipulation options in the
GOPATH documentation. Take a look at the other customization options as well.
If you haven't already done so, install and open Visual Studio Code. Navigate to the Extensions pane (Ctrl+Shift+X). Search for “Go” and install this extension (the publisher ID is
To activate the extension, open any directory or workspace containing Go code.
You should immediately see a prompt in the bottom-right corner of your screen titled
Analysis Tools Missing. This extension relies on a suite of command-line tools, which must be installed separately. Accept the prompt, or use the
Go: Install/Update Tools command to pick which tools you would like to install.
If you see an error that looks like
command Go: Install/Update Tools not found, it means that the extension has failed to activate and register its commands. Please uninstall and then reinstall the extension.
When the extension is active, you should see the Go status bar in the bottom left corner.
You're ready to Go!
Go modules have added a lot of complexity to the way that most tools and features are built for Go. Some, but not all, features of this extension have been updated to work with Go modules. Some features may also be slower in module mode. The features documentation contains more specific details.
This extension has a wide range of features, including Intellisense, code navigation, and code editing support. It also shows build, vet, and lint diagnostics as you work and provides enhanced support for testing and debugging your programs. For more detail, see the full feature breakdown.
In addition to integrated editing features, the extension also provides several commands for working with Go files. You can access any of these by opening the Command Palette (Ctrl+Shift+P) and typing in the name of the command. See the full list of commands provided by the extension.
The majority of the extension‘s functionality comes from command-line tools. If you’re experiencing an issue with a specific feature, you may want to investigate the underlying tool. You can do this by taking a look at the full list of tools used by this extension.
Debugging is a major feature offered by this extension. For a comprehensive overview of how to debug your Go programs, please see the debugging guide.
This extension needs no configuration; it works out of the box. However, you may wish to modify settings to adjust your experience.
Many of the features are configurable to your preference. A few common modifications are mentioned below, but take a look at the full list of settings for an overview.
A commonly customized feature is the linter, which is a tool used to provide coding style feedback and suggestions. By default, this extension uses the official
However, you are welcome to use more advanced options like
revive. This can be configured via the
"go.lintTool" setting, and the different options are explained more thoroughly in the list of diagnostic tools.
Advanced users may want to set different
GOPATHs for different projects or install the Go tools to a different
GOPATH. This is possible and explained in the
In the default mode, the Go extension relies upon a suite of command-line tools. A new alternative is to use a single language server, which provides language features through the Language Server Protocol.
The Go team at Google has developed
gopls, which is the official Go language server. It is currently in an alpha state and under active development.
gopls is recommended for projects that use Go modules.
To opt-in to the language server, set
true in your settings. You should then be prompted to install
gopls. If you are not prompted, you can install
gopls manually by running the
Go: Install/Update Tools command and selecting
For more information, see the
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.
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, please see our contribution guide. It explains how to build and run the extension locally, and it describes the process of sending a contribution.