Skip to content

Releases: golang/tools

gopls/v0.12.0

30 May 18:01
Compare
Choose a tag to compare

This release contains a major rewrite of the way gopls computes and stores package information, with the goal of reducing memory usage and allowing gopls to scale to larger repositories. This change can also significantly reduce startup time when workspaces are reopened, as gopls now uses a file-based cache to persist data across sessions. With these optimizations, gopls is finally able to fully analyze dependencies using the golang.org/x/tools/go/analysis framework, resulting in improved accuracy for analysis diagnostics.

You can install this release with go install:

go install golang.org/x/tools/gopls@v0.12.0

Support changes

As gopls matures, we're trying to simplify its configuration so that gopls Just Works in more scenarios, and so that we have fewer configuration combinations to test. This means that we will be gradually deprecating settings that affect the core behavior of gopls.

Removed experimental configuration options

As announced in the v0.10.0 release notes, this release removes support for the experimentalWorkspaceModule and experimentalWatchedFileDelay settings. The experimentalPackageCacheKey setting is also removed, as it is irrelevant in the new design.

The experimentalWorkspaceModule setting in particular may still be in use by some users. This setting has been superseded by built-in support for multi-module workspaces in the go command, via Go workspaces. To get the equivalent behavior in gopls@v0.12.0, please create a go.work file in your workspace using all desired modules. To use all modules in your workspace, run:

go work use -r .

Dropped support for Go 1.13-1.15, deprecated support for Go 1.16-1.17

As announced in the v0.10.0 release notes, this release drops support for Go 1.13-1.15, and in fact does not build with these Go versions.

Additionally, gopls@v0.12.x will be the final sequence of versions supporting Go 1.16-1.17, and therefore displays a deprecation notice when used with these Go versions.

Supported operating systems

Given that our users are almost entirely on Linux, Windows, or Darwin, we are discussing narrowing our support to focus on those operating systems, in golang/go#59981.

Performance improvements

The banner feature of this release is an internal redesign that significantly improves the way gopls scales in larger codebases. Performance, particularly memory usage, has long been a pain point for our users.

Reduced memory usage

Previous releases of gopls held typed syntax trees for all packages, in memory, all the time. With this release, these large data structures are ephemeral: as soon as they are constructed, an index of information derived from them is saved persistently to a file-based cache, and the data structures are recycled. The index for each package includes the locations of declaring and referring identifiers; the set of exported declarations and their types; the method sets of each interface; and any diagnostics and facts (see below) produced during analysis. The index holds all the information needed to serve global-scope LSP queries such as β€œreferences”, β€œimplementations”, and so on.

Moving package information to a file-based cache greatly reduces the amount of RAM gopls uses, by almost an order of magnitude in larger projects. The table below shows the reductions in steady-state memory usage for three open-source Go repositories.

Project Packages In-use bytes v0.11.0 v0.12.0 Change
gopls 405 497MB 232MB -53%
kubernetes 3137 3090MB 832MB -73%
google-cloud-go + submods 7657 5039MB 863MB -83%

Improved invalidation

Internally, gopls now resembles an incremental build system such as go build, which recompiles only the packages that have changed due to edits since the last build. If neither the inputs nor the configuration have changed, gopls can reuse the result previously computed.

Nonetheless, a change to a low-level package may in principle affect a large number of other packages. In practice though, the effects of many common changes, such as adding a statement within a function body, are local. So, gopls computes symbol dependencies at a much finer grain than the import dependency graph so that it can safely avoid invalidating packages that cannot be affected by local changes to their dependencies.

Gopls also now employs a number of more modest optimizations that may be characterized as β€œdo less”. For example, many operations previously requested type information that wasn’t needed in most cases, or requested parsed syntax trees when raw file content would do. We have reduced the demand for unnecessary but computationally expensive steps.

How well is gopls performing for you?

We expect this release to make gopls faster for all users, but it involves a lot of new machinery. We’d love to hear how well it works for you and how it affects performance in your workspace. Has it improved the way you work? Are there ways it could do better? Let us know by filling out our survey or reporting an issue.

The gopls stats command provides some metrics that may be useful when filing issues to help us understand performance problems and bugs. Please review its output before sharing, or use the -anon flag if you prefer not to share any fields that might identify you or the names of your files.

New features

Improved static analysis

This release includes a new driver for golang.org/x/tools/go/analysis static checkers (as used in go vet) that supports β€œfacts”. Facts are deductions made during analysis of one package that may be assumed during analysis of another package. When the printf format-string checker encounters a function MyPrintf that delegates to fmt.Sprintf, it records this information as a fact about MyPrintf. This fact enables argument checking for calls to MyPrintf too, so gopls will emit a diagnostic for any call to MyPrintf with arguments of the wrong type for the format string.

Here’s an example from gopls’ own code base. The Hashf function, defined in package source, is a wrapper around fmt.Sprintf.
image

The code below illustrates a call to source.Hashf with a formatting mistake, which gopls reports:
image

Gopls’ support for analysis facts thus enables it to discover and report many more diagnostics about your code than in previous releases.

Other features

Quick fixes to help manage go.work files

Gopls now pr...

Read more

gopls/v0.12.0-pre.3

24 May 19:31
Compare
Choose a tag to compare
gopls/v0.12.0-pre.3 Pre-release
Pre-release

This third prerelease contains several bug fixes following the v0.12.0-pre.2 release, and again contains some additional performance improvements. If all goes well. we plan to promote this to v0.12.0 on Tue May 30.

You can install this prerelease with go install:

go install golang.org/x/tools/gopls@v0.12.0-pre.3

To revert to the last stable release, run go install golang.org/x/tools/gopls@latest (though given that this is a release candidate, if you need to do this please file an issue).

Changes since pre.2

The most significant bug fix (golang/go#60089) relates to the file-watching mechanism by which gopls requests file change notifications from the client editor. Previously, gopls would generate a large glob pattern that, in large workspaces, would cause VSCode to get stuck. Now, gopls generates many smaller patterns, which works well with VSCode but may cause other editors (e.g. coc.nvim) to slow down. So, the new behavior is enabled automatically based on the client type, though it can be controlled explicitly using the new subdirWatchPatterns setting (golang/go#59635).

The file-based cache introduced in gopls v0.12 has been simplified in this pre-release, borrowing a number of ideas from the go command's module cache. It achieves atomic updates using more reliable and portable system calls. It uses a simpler directory structure, saving space. It avoids most metadata update operations in its LRU eviction. And it uses an additional memory-based caching layer to avoid disk access in most cache-hit cases.

Other highlights:

  • a number of optimizations related to go mod tidy operation (golang/go#60089);
  • a limit on the module scan, which was causing slow startup in some cases (golang/go#56496);
  • placeholders for the name and type of each argument in completion of calls to unimported packages (golang/go#60269);
  • a race fixed in in reloading of package metadata for ad-hoc packages (golang/go#57209);
  • a new gopls stats -anon flag that redacts fields potentially containing user information.

In this release, we also announce the end of gopls' support for versions go1.16 and go1.17 of the go command. (golang/go#60341)

How to report a problem

As always, you can report gopls problem by filing an issue. We are particularly interested in any regressions you observe since gopls@v0.11.0.

If you would prefer not to report an issue on the issue tracker, you can also reach out to us via email to rfindley@google.com or adonovan@google.com.

gopls/v0.12.0-pre.2

16 May 21:32
Compare
Choose a tag to compare
gopls/v0.12.0-pre.2 Pre-release
Pre-release

This second prerelease contains many bug fixes following the v0.12.0-pre.1 release. It also contains some minor additional performance improvements. See the release milestone for more details.

The gopls@v0.12.0 release contains an internal redesign of gopls for improved scalability. This prerelease should use much less memory than v0.11.0. See the v0.12.0-pre.1 release notes for more information.

How to report a problem

As always, you can report gopls problem by filing an issue. We are particularly interested in any regressions you observe since gopls@v0.11.0.

If you would prefer not to report an issue on the issue tracker, you can also reach out to us via email to rfindley@google.com or adonovan@google.com.

What's next?

We have a few more small bugfixes to get in before the final v0.12.0 release. We will likely cut a third (and hopefully final) prerelease next week.

gopls/v0.12.0-pre.1

25 Apr 13:53
Compare
Choose a tag to compare
gopls/v0.12.0-pre.1 Pre-release
Pre-release

This prerelease version of gopls contains a major rewrite of the way gopls computes and stores package information, with the goal of reducing memory usage and allowing gopls to scale to larger repositories. This change can also significantly reduce startup time the second time a workspace is opened, as gopls now uses a file-based cache to preserve derived package information across sessions. With these optimizations, gopls is finally able to fully analyze dependencies using the x/tools/go/analysis framework, resulting in improved accuracy for analysis diagnostics.

We'd love help testing this large change! If you are interested, please see below for details on what to expect, and how to report problems.

What to expect

In general, gopls@v0.12.0-pre.1 should behave similarly to gopls@v0.11.0, but use much less memory. Memory savings typically range from 50-90%, depending on the shape of your repository. Note that memory will peak higher during startup or large operations, but should ideally never go as high as with gopls@v0.11.0, and in-use memory should stabilize at a much lower number. To see details about current memory usage, start gopls with -debug=localhost:8080 and visit http://localhost:8080/memory.

As part of the rewrite, certain operations may have gotten slightly slower overall, whereas others may have gotten slightly faster (e.g. see our performance dashboard). No operation should become unusably slow.

However, it is possible that gopls' new execution model performs disproportionately worse on certain operating systems, file systems, or repositories. If you encounter this, please let us know. See below for details on how to report a problem.

Support changes

This version of gopls implements the support changes discussed in the v0.10.0 release notes. Notably, it does not support Go 1.13-1.15, and removes support for several experimental features.

How to report a problem

You can always report a gopls problem by filing an issue. We are particularly interested in any regressions you observe since gopls@v0.11.0.

If you would prefer not to report an issue on the issue tracker, you can also reach out to us via email to rfindley@google.com or adonovan@google.com.

We are aware of a number of remaining issues or regressions with the new release, tracked in the v0.12.0 milestone.

What's next?

We will continue to polish this release, and fix known regressions. We may make additional small performance improvements but do not expect large changes. Nevertheless, since this release constitutes a fundamental change to the way gopls works, we will likely cut one or more additional prereleases before the final release.

Looking beyond the v0.12.0 release, the recent redesign work paves the way for our next effort to make gopls self-configuring in more scenarios. With the previous design this would have been prohibitively expensive in memory, but soon gopls should just Do The Right Thing when you open any Go file on your machine.

gopls/v0.11.0

14 Dec 16:51
Compare
Choose a tag to compare

This is a small release containing new integrations of vulnerability analysis.

Vulnerability analysis for go.mod files can be enabled by configuring the "vulncheck" setting to "Imports". For more information on vulnerability management, see the Vulnerability Management for Go blog post.

Support changes

This release removes support for the "experimentalUseInvalidMetadata" setting, as described in the v0.10.0 release. Other settings slated for deprecation in that release remain temporarily supported, but will be removed in v0.12.0.

New Features

Analyzing dependencies for vulnerabilities

This release offers two different options for detecting vulnerabilities in dependencies. Both are backed by the Go vulnerability database (https://vuln.go.dev) and complement each other.

  • Imports-based scanning, enabled by the "vulncheck": "Imports" setting, reports vulnerabilities by scanning the set of packages imported in the workspace. This is fast, but may report more false positives.
  • Integration of the golang.org/x/vuln/cmd/govulncheck command-line tool performs a more precise analysis based on-call graph reachability, with fewer false positives. Because it is slower to compute, it must be manually triggered by using "Run govulncheck to verify" code actions or the "codelenses.run_govulncheck" code lens on go.mod files.
vulncheck.mp4

Checking for vulnerabilities using VS Code Go v0.37.0 and Gopls v0.11.0

Additional checks for the loopclosure analyzer

The loopclosure analyzer, which reports problematic references from a nested function to a variable of an enclosing loop, has been improved to catch more cases. In particular, it now reports when subtests run in parallel with the loop, a mistake that often results in all but the final test case being skipped.

image

Configuration changes

  • The "vulncheck" setting controls vulnerability analysis based on the Go vulnerability database. If set to "Imports", gopls will compute diagnostics related to vulnerabilities in dependencies, and will present them in go.mod files.
  • The "codelenses.run_govulncheck" setting controls the presence of code lenses that run the govulncheck command, which takes longer but produces more accurate vulnerability reporting based on call-graph reachability.

Bug fixes

This version of gopls includes fixes to several bugs, notably:

A full list of all issues fixed can be found in the gopls/v0.11.0 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new.

Thank you to our contributors

@Arsen6331, @SN9NV, @adonovan, @bcmills, @dle8, @findleyr, @hyangah, @pjweinbgo, @suzmue

gopls/v0.10.1

01 Nov 19:35
Compare
Choose a tag to compare

This release contains a fix for golang/go#56505: a new crash during method completion on variables of type *error.

Thank you to everyone who filed a crash report.

gopls/v0.10.0

31 Oct 16:23
Compare
Choose a tag to compare

This release contains initial support for standalone packages and package renaming. Please see below for more details.

We are also changing our release policy to better align with semver.

Support changes

This version of gopls contains changes to our release policy, deprecates support for some older Go versions, and deprecates support for several experimental features.

New release policy

As described in golang/go#55267, we are tightening our release policy to better follow semver, increase stability, and reduce release-related toil. Significant new features will only be introduced in *.*.0 patch versions, and subsequent patch releases will consist only of bugfixes. For example, this version (v0.10.0) introduces several new features, described below. Subsequent v0.10.* releases will contain only bugfixes.

Final support for Go 1.13-1.15

Consistent with the above release policy and our stated support window, the v0.10.* minor version will be the final set of releases to support being used with Go 1.13-1.15. See golang/go#52982 for details.

Gopls will pop up a warning if it resolves a version of the go command that is older than 1.16. Starting with gopls@v0.11.0, gopls will cease to function when used with a go command with a version older than 1.16.

Deprecated experimental features

The following experimental features are deprecated, and will be removed in gopls@v0.11.0:

  • experimentalWorkspaceModule (golang/go#52897): this feature has been replaced by go.work files. See our documentation for information on how to use go.work files to work on multiple modules.
  • experimentalWatchedFileDelay (golang/go#55268): LSP clients should instead be responsible for buffering workspace/didChangeWatchedFiles notifications.
  • experimentalUseInvalidMetadata (golang/go#54180): we are going to focus instead on improving diagnostics for broken workspaces.

New Features

Support for "standalone packages"

Gopls now recognizes certain files as "standalone main packages", meaning they should be interpreted as main packages consisting of a single file. To do this, gopls looks for packages named main containing a single build constraint that matches one of the tags configured by the new standaloneTags setting.

This enables cross references and other features when working in a file such as the example below that contains a //go:build ignore build constraint.

image

(preview) Support for package renaming

This version of gopls contains initial support for renaming packages (golang/go#41567). This is a work in progress and has a surprising number of edge cases. Additionally, this feature depends heavily on LSP client behavior: renaming a package involves moving the underlying package directory, which may behave differently in different editors. Please try it out, and report your experience at golang/go#56184.

To rename a package, initiate a rename request on the package clause of a file in the package:
image

When this renaming is applied, gopls will adjust other package files accordingly, rename the package directory, and update import paths referencing the current package or any nested package in the renamed directory.
image

Method information in hover

Hovering over a type now shows a summary of its methods.

image

Support for Go 1.19 doc comment syntax

This version of gopls supports the new doc comment syntax added in Go 1.19. See https://go.dev/doc/comment for more details.

image

New diff algorithm

This version of gopls uses an entirely new diff algorithm behind the scenes, to compute the text edits that gopls sends to the LSP client. We hope that this fixes a number of bugs in the old diff implementation, but for the most part you should not notice any effect of this change. If you do experience problems related to text edits, please report an issue and set the "newDiff" setting to "old" to revert to the old diff algorithm.

Configuration changes

This release changes the default value of the "directoryFilters" setting from ["-node_modules"] to ["-**/node_modules"], following support for wildcard syntax.

Bug fixes

This version of gopls includes several bug fixes, notably:

A full list of all issues fixed can be found in the gopls/v0.10.0 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new.

Thank you to our contributors!

@adonovan, @brianpursley, @findleyr, @hyangah, @pjweinbgo, @suzmue, and @dle8!

gopls/v0.10.0-pre.2

21 Oct 15:04
Compare
Choose a tag to compare
gopls/v0.10.0-pre.2 Pre-release
Pre-release

The following release notes are for a pre-release version of gopls, to be released as gopls@v0.10.0. To install this prerelease, please run the following:

go install golang.org/x/tools/gopls@v0.10.0-pre.2

Note: These changes have since been released as gopls@v0.10.0. Please see the release notes for that version for more information.

gopls/v0.9.5

08 Sep 20:00
Compare
Choose a tag to compare

This release updates the gopls vulncheck command (which backs the preview of vulncheck integration in VS Code) with the latest schema of the Go vulnerability database. See the Vulnerability Management for Go blog post for more context.

Additionally, this release includes a bugfix for redundant reloads following go.mod changes (golang/go#54473).

gopls/v0.9.4

15 Aug 17:18
Compare
Choose a tag to compare

This release fixes an unfortunate bug in a new vet analysis in the gopls@v0.9.2 release. Specifically, a stray print statement in a new analyzer for the invalid time format string "2006-02-01", which corrupts gopls' communication over STDIN/STDOUT.

This only affects projects using that bad format string, and only when a file in the affected package is open. Thanks to @Phadin for accurately identifying this bug so quickly after it was introduced. Issue golang/go#54459 tracks our follow-up to prevent similar regressions from making it into future gopls releases.

On a positive note, here is the new vet analysis in action. Clearly it will catch real bugs!

image