gopls/v0.15.0

These release notes are mostly identical to the v0.15.0-pre.3 prerelease notes. Thanks to all who tested the prerelease!

go install golang.org/x/tools/[email protected]

This release introduces "zero config" gopls workspaces, which is a set of heuristics allowing gopls to Do The Right Thing when you open a Go file. We believe this addresses two of the largest pain points we hear about from our users: difficulty configuring multi-module repositories, and working on multiple GOOS/GOARCH combinations. However, this is a large change to the way gopls models your workspace, and the dynamic loading/unloading of builds may be surprising in some cases. Your feedback on this new feature is greatly appreciated. See below for more details.

New Features

Simpler workspace configuration and improved build tag support

The headline feature of this release is a rewrite of gopls's logic for associating files with build configurations that enables gopls to give accurate answers when navigating almost any Go source file on your machine.

Most features of gopls rely on type information, which comes not from the file in isolation but depends on the relationship between the file and the other files in its package, and between the package and all its dependencies; this in turn depends on go.mod and go.work files. In effect, gopls needs to decide which go build command--which working directory, package arguments, GOOS, GOARCH, build tags, and so on--would cause each file to be processed by the compiler.

Previous versions of gopls only allowed one build per workspace folder, and users had to be careful to configure the right workspace root and build environment. As a result, users often encountered confusing error messages when they opened the wrong directory, or a file that was tagged for a different operating system or architecture--the dreaded "No packages found" error. This situation was improved by the introduction of go.work files, but still required configuration and a preexisting understanding of the code being edited.

With this release, gopls now allows multiple builds per workspace, and uses heuristics to automatically derive the set of active builds. Gopls will ensure that an active build contains every module with an open file in your workspace, adding new builds and GOOS/GOARCH combinations as needed to cover files that don't match the host operating system or architecture.

For example, suppose we had a repository with three modules: moda, modb, and modc, and a go.work file using modules moda and modb. If we open the files moda/a.go, modb/b.go, moda/a_windows.go, and modc/c.go, gopls will automatically create three builds:

This allows gopls to just work when you open a Go file, but it does come with several caveats:

• This causes gopls to do more work, since it is now tracking three builds instead of one. However, the recent scalability redesign allows much of this work to be avoided through efficient caching.
• For operations invoked from a given file, such as "References" and "Implementations", gopls executes the operation in the default build for that file. For example, finding references to a symbol S from foo_linux.go will return references from the Linux build, and finding references to the same symbol S from foo_windows.go will return references from the Windows build. Gopls searches the default build for the file, but it doesn't search all the other possible builds because it is liable to be too expensive. golang/go#65757 and golang/go#65755 propose improvements to this behavior.
• When selecting a GOOS/GOARCH combination to match a build-constrained file, gopls will choose the first matching combination from this list. In some cases, that may be surprising.
• When working in a GOOS/GOARCH constrained file that does not match your default toolchain, CGO_ENABLED=0 is implicitly set, since a C toolchain for that target is unlikely to be available. This means that gopls will not work in files including import "C". golang/go#65758 may lead to improvements in this behavior.
• Gopls is currently unable to guess build flags that include arbitrary user-defined build constraints. For example, if you are trying to work on a file that is constrained by the build directive //go:build special, gopls will not guess that it needs to create a build with "buildFlags": ["-tags=special"]. golang/go#65089 proposes a heuristic by which gopls could handle this automatically.

Please provide feedback on this behavior by upvoting or commenting the issues mentioned above, or opening a new issue for other improvements you'd like to see.

Preview refactoring edits

Refactoring code actions now support resolving edits. This update enables features like code action previews within VS Code (triggered by Ctrl+Enter).

To take advantage of this new gopls feature, clients must register support via:

{
	"textDocument": {
		"codeAction": {
			"dataSupport": true,
			"resolveSupport": {
				"properties": ["edit"]
			}
		}
	}
}

Analysis & diagnostics

This release includes two new analyzers:

• The nilness analyzer reports mistakes relating to nil pointers. (In previous releases it was off by default because it was too computationally expensive, but it has since been optimized.)

• The unusedparams analyzer reports when a parameter is unused, and offers quick fixes to either rename it to _ or to remove it completely and update all callers. (This analyzer was also previously off by default because it was too imprecise, but it has been rewritten to eliminate nearly all false positives.)

Automated crash reporting (off by default)

The v1.23 release of Go expected in August contains a feature that makes it possible for a Go program to monitor itself for unexpected crashes of any kind. When gopls is built with the latest Go toolchain, it will enable this feature and save crash reports into the local telemetry database.

If you have elected to enable data collection by running this command:

$ go run golang.org/x/telemetry/cmd/gotelemetry@latest on

then these crash reports will be uploaded to https://telemetry.go.dev, helping us identify crashes and quickly fix them.

We respect your privacy. The crash reports contain only stack traces, that is, lists of names of functions from the gopls source code. They do not contain any values derived from your source code or environment.

The v0.14 release of gopls reported limited telemetry data about a handful of sites in the code where we had added explicit assertions. We are grateful to users who enabled telemetry as even this limited data proved tremendously valuable and led to numerous bug fixes.

Housekeeping

Finishing up the redesign work from v0.12, we've made a number of clarifications to the internal structure of the project, including rationalizing the directory layout, breaking dependencies, minimizing and documenting our internal APIs, and converging our tests on a standard form. We believe it is now easier than ever before to contribute features to gopls, and have been heartened by an uptick in contributions from the broader community, including:

• improved postfix completion (golang/go#64178, golang/go#64037, golang/go#59689);
• improved completion of return statements (golang/go#64266);
• a new code action (refactoring) for conversion between raw and interpreted string literals (golang/go#51200);
• updating of doc links when renaming a symbol (golang/go#64495);
• semantic highlighting for go: directives (golang/go#63538)

Bug fixes

In addition to the new features listed above, this release includes numerous minor ones, including:

• The "add missing imports" feature (typically invoked on save) is much less likely to block, a commonly reported source of freezing following a save (golang/go#59216).
• Hovering over a type now displays the set of accessible fields and methods, even though embedded fields (golang/go#61634).
• gopls supports "workspace vendoring" (golang/go#63375).
• Completion now substitutes type arguments in generic snippets when they are known (golang/go#61189).
• Completion now omits type parameters when they can be inferred from the arguments (golang/go#51783).

A major theme for this release is stability: we have fixed a large number of crash bugs.

A full list of all issues fixed can be found in the...

gopls/v0.15.0-pre.3

These are release notes for a prerelease version of gopls. v0.15.0 will be released soon, but please try the prerelease if you can!

go install golang.org/x/tools/[email protected]

This release introduces "zero config" gopls, which is a set of heuristics allowing gopls to Do The Right Thing when you open a Go file. We believe this addresses the two largest pain points we hear about from our users: difficulty configuring multi-module repositories, and working on multiple GOOS/GOARCH combinations. However, this is a large change to the way gopls models your workspace, and the dynamic loading/unloading of builds may be surprising in some cases. Your feedback on this new feature is greatly appreciated. See below for more details.

New Features

Simpler workspace configuration and improved build tag support

The headline feature of this release is a rewrite of gopls's logic for associating files with build configurations that enables gopls to give accurate answers when navigating almost any Go source file on your machine.

Most features of gopls rely on type information, which comes not from the file in isolation but depends on the relationship between the file and the other files in its package, and between the package and all its dependencies; this in turn depends on go.mod and go.work files. In effect, gopls needs to decide which go build command--which working directory, package arguments, GOOS, GOARCH, build tags, and so on--would cause each file to be processed by the compiler.

Previous versions of gopls only allowed one build per workspace folder, and users had to be careful to configure the right workspace root and build environment. As a result, users often encountered confusing error messages when they opened the wrong directory, or a file that was tagged for a different operating system or architecture--the dreaded "No packages found" error. This situation was improved by the introduction of go.work files, but still required configuration and a preexisting understanding of the code being edited.

With this release, gopls now allows multiple builds per workspace, and uses heuristics to automatically derive the set of active builds. Gopls will ensure that an active build contains every module with an open file in your workspace, adding new builds and GOOS/GOARCH combinations as needed to cover files that don't match the host operating system or architecture.

For example, suppose we had a repository with three modules: moda, modb, and modc, and a go.work file using modules moda and modb. If we open the files moda/a.go, modb/b.go, moda/a_windows.go, and modc/c.go, gopls will automatically create three builds:

In some cases this may cause gopls to do more work, since gopls is now tracking three builds instead of one. However, the scalability redesign we first announced in v0.12 allows us to avoid most of this work by efficient caching in a persistent store.

So, all gopls' navigation, query, analysis, and refactoring features should work equally well in both files. Notably, you'll see compiler diagnostics for the appropriate build in real time, making it much easier to make changes to cross-platform code.

Preview refactoring edits

Refactoring code actions now support resolving edits. This update enables features like code action previews within VS Code (triggered by Ctrl+Enter).

To take advantage of this new gopls feature, clients must register support via:

{
	"textDocument": {
		"codeAction": {
			"dataSupport": true,
			"resolveSupport": {
				"properties": ["edit"]
			}
		}
	}
}

Analysis & diagnostics

This release includes two new analyzers:

• The nilness analyzer reports mistakes relating to nil pointers. (In previous releases it was off by default because it was too computationally expensive, but it has since been optimized.)

• The unusedparams analyzer reports when a parameter is unused, and offers quick fixes to either rename it to _ or to remove it completely and update all callers. (This analyzer was also previously off by default because it was too imprecise, but it has been rewritten to eliminate nearly all false positives.)

Automated crash reporting (off by default)

The v1.23 release of Go expected in August contains a feature that makes it possible for a Go program to monitor itself for unexpected crashes of any kind. When gopls is built with the latest Go toolchain, it will enable this feature and save crash reports into the local telemetry database.

If you have elected to enable data collection by running this command:

$ go run golang.org/x/telemetry/cmd/gotelemetry@latest on

then these crash reports will be uploaded to https://telemetry.go.dev, helping us identify crashes and quickly fix them.

We respect your privacy. The crash reports contain only stack traces, that is, lists of names of functions from the gopls source code. They do not contain any values derived from your source code or environment.

The v0.14 release of gopls reported limited telemetry data about a handful of sites in the code where we had added explicit assertions. We are grateful to users who enabled telemetry as even this limited data proved tremendously valuable and led to numerous bug fixes.

Housekeeping

Finishing up the redesign work from v0.12, we've made a number of clarifications to the internal structure of the project, including rationalizing the directory layout, breaking dependencies, minimizing and documenting our internal APIs, and converging our tests on a standard form. We believe it is now easier than ever before to contribute features to gopls, and have been heartened by an uptick in contributions from the broader community, including:

• improved postfix completion (golang/go#64178, golang/go#64037, golang/go#59689);
• improved completion of return statements (golang/go#64266);
• a new code action (refactoring) for conversion between raw and interpreted string literals (golang/go#51200);
• updating of doc links when renaming a symbol (golang/go#64495);
• semantic highlighting for go: directives (golang/go#63538)

Bug fixes

In addition to the new features listed above, this release includes numerous minor ones, including:

• The "add missing imports" feature (typically invoked on save) is much less likely to block, a commonly reported source of freezing following a save (golang/go#59216).
• Hovering over a type now displays the set of accessible fields and methods, even though embedded fields (golang/go#61634).
• gopls supports "workspace vendoring" (golang/go#63375).
• Completion now substitutes type arguments in generic snippets when they are known (golang/go#61189).
• Completion now omits type parameters when they can be inferred from the arguments (golang/go#51783).

A major theme for this release is stability: we have fixed a large number of crash bugs.

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

End of support for Go 1.18

This is the last release of gopls that may be built and used with Go 1.18. If built or used with Go 1.18, it will display a message advising the user to upgrade. See supported Go versions for details.

gopls/v0.14.2

This release contains just one change: an upgrade of x/telemetry to pick up support for the "local" telemetry mode (golang/go#63832).

Previously, when the telemetry mode was "off" (the default), counter data would not be uploaded, but would be written to the os.UserConfigDir()/go/telemetry/local directory of the local file system. We heard from a few users that, as a matter of policy within their organization, they need a way to prevent even this local data from being written. With this release, running gotelemetry off will stop gopls from writing this local counter data. Note that the os.UserConfigDir()/go/telemetry/mode file must be written to record the "off" state.

The new default telemetry mode is "local", which behaves the same way as "off" did before. In "local" mode, counter data is written to the local file system, but not uploaded. Local data can be inspected with the gotelemetry view command.

See golang/go#63832 for more details. Thanks again for helping us support transparent telemetry in gopls. As described in the v0.14.0 release notes, we are confident that this data will help us produce a better, faster, more reliable product. In fact this is already happening.

gopls/v0.14.1

This release contains just two changes:

• A workaround for a regression affecting some users of GOPACKAGESDRIVER: golang/go#63751, for example those using gopls with an older version of Bazel. When the go/packages driver is missing compiler or architecture information, gopls now assumes a default value rather than failing to load package information.
• A fix for a minor bug in the new "remove unused parameter" refactoring: golang/go#63755. Notably, this bug was discovered via an automated report from someone who had opted in to Go telemetry.

gopls/v0.14.0

These are release notes are identical to the v0.14.0-pre.4 prerelease notes. Thanks to all who tested the prerelease!

go install golang.org/x/tools/[email protected]

This release includes initial support for the "inline call to function" refactoring, as well as a few other smaller features. It also includes several bug fixes, notably a fix for a performance regression in completion that may be significant in some environments.

The release also contains support for opt-in telemetry. If you want, you can enable the periodic uploading of telemetry data, including gopls stack traces and metrics, but never your source code, to telemetry.go.dev. See below for details.

New Features

Refactoring: inline call to function

This release includes a new code action to inline function calls:

While the outcome of this operation may be a simple replacement, there's a lot going on under the covers. For example, the new inliner checks whether changes to the order of argument evaluation could have unintended consequences. If so, it is careful to replicate the original behavior:

add preserves the order of effects	...but sub does not

The goal of the inliner is to rewrite your code idiomatically without introducing behavior changes. See the inlining documentation for more details.

When the call cannot be reduced to a simple expression, the inliner may fall back on an immediately invoked function literal (func() { statements }()) as this is often the only way to preserve the original behavior. As we continue to work on refactoring, we'll add additional rewriting strategies that avoid this fall-back in more cases.

Refactoring: removing unused parameters

The techniques described in the previous section serve as a foundation for other refactoring operations. As a proof of concept, this release also includes a code action to remove unused parameters. Since this operation uses inlining behind the scenes, it gets all of the related safety checks and rewriting strategies for free:

Improved support for go:embed directives

This release includes improved support for //go:embed directives, including hover and jump-to-definition.

New analyses

This release include three new static analyses, all of which are enabled by default.

"appends": reports calls to append that pass no values to be appended to the slice.

"defers": checks for common mistakes in defer statements.

"slog": checks for invalid structured logging calls.

Opt-in telemetry

This is the first gopls release to include opt-in transparent telemetry. Telemetry uploading is off by default, and can be enabled with the following command:

go run golang.org/x/telemetry/cmd/gotelemetry@latest on

After telemetry is enabled, gopls will periodically upload metrics and stack traces to telemetry.go.dev. If we get enough adoption, this data can significantly advance the pace of gopls development and help us meet a higher standard of reliability. For example:

• Even with semi-automated crash reports in VS Code, we've seen several crashers go unreported for weeks or months.
• Even with a suite of benchmarks, some performance regressions don't show up in our benchmark environment (such as the completion bug mentioned below!).
• Even with lots of great ideas for how to improve gopls, we have limited resources. Telemetry can help us identify which new features are most important, and which existing features aren't being used or aren't working well.

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.

Bugfixes

• Completion latency: the most notable bug fixed in this release is a regression in completion latency that first appeared in [email protected]. This bug relates to scanning the module cache for completion of functions in unimported packages, so in environments where this operation is slow, completion latency was markedly higher. Thanks @myitcv for the detailed bug report that allowed us to root cause this regression.

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

Thank you to our contributors!

@adonovan @bcmills @cuishang @cuonglm @dmitshur @ericlohyg @findleyr @hyangah @jba @lfolger @nchengyeeshen @pjweinb @qiulaidongfeng @telemachus @timothy-king @tttoad @vikblom

gopls/v0.14.0-pre.4

These are release notes for a prerelease version of gopls. v0.14.0 will be released soon, but please try the prerelease if you can!

go install golang.org/x/tools/[email protected]

This release includes initial support for the "inline call to function" refactoring, as well as a few other smaller features. It also includes several bug fixes, notably a fix for a performance regression in completion that may be significant in some environments.

The release also contains support for opt-in telemetry. If you want, you can enable the periodic uploading of telemetry data, including gopls stack traces and metrics, but never your source code, to telemetry.go.dev. See below for details.

New Features

Refactoring: inline call to function

This release includes a new code action to inline function calls:

While the outcome of this operation may be a simple replacement, there's a lot going on under the covers. For example, the new inliner checks whether changes to the order of argument evaluation could have unintended consequences. If so, it is careful to replicate the original behavior:

add preserves the order of effects	...but sub does not

The goal of the inliner is to rewrite your code idiomatically without introducing behavior changes. See the inlining documentation for more details.

When the call cannot be reduced to a simple expression, the inliner may fall back on an immediately invoked function literal (func() { statements }()) as this is often the only way to preserve the original behavior. As we continue to work on refactoring, we'll add additional rewriting strategies that avoid this fall-back in more cases.

Refactoring: removing unused parameters

The techniques described in the previous section serve as a foundation for other refactoring operations. As a proof of concept, this release also includes a code action to remove unused parameters. Since this operation uses inlining behind the scenes, it gets all of the related safety checks and rewriting strategies for free:

Improved support for go:embed directives

This release includes improved support for //go:embed directives, including hover and jump-to-definition.

New analyses

This release include three new static analyses, all of which are enabled by default.

"appends": reports calls to append that pass no values to be appended to the slice.

"defers": checks for common mistakes in defer statements.

"slog": checks for invalid structured logging calls.

Opt-in telemetry

This is the first gopls release to include opt-in transparent telemetry. Telemetry uploading is off by default, and can be enabled with the following command:

go run golang.org/x/telemetry/cmd/gotelemetry@latest on

After telemetry is enabled, gopls will periodically upload metrics and stack traces to telemetry.go.dev. If we get enough adoption, this data can significantly advance the pace of gopls development and help us meet a higher standard of reliability. For example:

• Even with semi-automated crash reports in VS Code, we've seen several crashers go unreported for weeks or months.
• Even with a suite of benchmarks, some performance regressions don't show up in our benchmark environment (such as the completion bug mentioned below!).
• Even with lots of great ideas for how to improve gopls, we have limited resources. Telemetry can help us identify which new features are most important, and which existing features aren't being used or aren't working well.

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.

Bugfixes

• Completion latency: the most notable bug fixed in this release is a regression in completion latency that first appeared in [email protected]. This bug relates to scanning the module cache for completion of functions in unimported packages, so in environments where this operation is slow, completion latency was markedly higher. Thanks @myitcv for the detailed bug report that allowed us to root cause this regression.

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

Thank you to our contributors!

@adonovan @bcmills @cuishang @cuonglm @dmitshur @ericlohyg @findleyr @hyangah @jba @lfolger @nchengyeeshen @pjweinb @qiulaidongfeng @telemachus @timothy-king @tttoad @vikblom

gopls/v0.13.2

This release includes just one change: a fix for a new crash when renaming methods in certain packages (golang/go#61813).

gopls/v0.13.1

This is a patch release to fix three issues with the v0.13.0 release:

• golang/go#61670: broken imports due to corrupted export data
• golang/go#61693: panic in stubmethods with variadic args
• golang/go#61692: gofumpt integration panics when used with the new go directive syntax in go.mod files (e.g. go 1.21rc3)

Incidentally, this release also picks up a few fixes for references and renaming. See the milestone for the complete list of resolved issues.

Thank you to all who reported bugs. If are still encountering problems, please file an issue.

gopls/v0.13.0

These are release notes are identical to that of [email protected]. Thanks to all who tested the prerelease!

go install golang.org/x/tools/[email protected]

This release fixes several bugs and mitigates a few performance regressions. It also somewhat reduces the latency and CPU cost of most operations, and includes a few small additional features.

Performance improvements

While [email protected] drastically reduced memory usage, several operations got around 50% slower due to additional I/O reading from the filesystem and time spent decoding indexes. This release optimizes those additional operations to (in most cases) achieve parity or better with the equivalent operation in [email protected]. Additionally, this release reduces total CPU while typing or performing common operations.

Faster code actions

This release includes a particularly large performance improvement in the evaluation of code actions (including formatting/goimports on save). In the past, there have been several reasons why this operation was expensive -- VS Code users may recognize the getting code actions from "Go" pop-up. This release fundamentally changes the way code actions are evaluated so that almost all of the work is pre-computed. As a result, formatting and adding or removing imports on save should be much faster.

Analysis performance

A notable exception to CPU performance parity with [email protected] is running static analysis. In this case, the additional cost incurred by [email protected] was not a regression, but rather the cost of analyzing many more packages to enable "deep" static analysis (see "Improved static analysis" in the [email protected] release notes.

In smaller repositories, the cost of this additional analysis is negligible -- analysis does not run until you stop typing, and typically just re-evaluates the changed package. However, it was discovered that in large workspaces that import low-level packages with a very large API surface (such as a cloud provider SDK or proto library), certain quadratic factors involved with the encoding/decoding of analysis results can dominate the cost of analysis, and result in enormous resource consumption: overloading the CPU and exhausting all memory.

This release partially mitigates those quadratic factors, significantly reducing their cost and limiting concurrency so that they do not exhaust all resources. However, fully eliminating these factors will require additional work to fix their quadratic nature. Until that is done, analysis may continue to be costly on certain repos, especially if "staticcheck" is enabled (because staticcheck does more deep analysis than the default set of analyzers).

In the meantime, a notification is added to make you aware when analysis is slow, and provide an update on the progress of indexing "deep" analysis results. Canceling this notification will cancel the ongoing analysis, but it will resume after the next change. If you don't want to see these notifications, you can set the new "analysisProgressReporting" setting to "false".
.

New Features

Highlight deprecated symbols

Deprecated symbols and packages are now marked as such. To turn off this feature, disable the "deprecated" analysis.

Stub methods to fix missing method errors

The "stubmethods" refactoring is now available as a quick-fix for errors related to missing methods.

Improvements to function extraction

Function extraction now puts context.Context parameters first in the resulting extracted function. See golang/go#60738 for details.

Improvements to the embeddirective analyzer

The embed directive analyzer now verifies the location of //go:embed directives, and provides a quick-fix to add missing "embed" imports.

Bug fixes

In addition to the performance fixes listed above, this release fixes a couple crashes. A full list of all issues fixed can be found in the gopls/v0.13.0 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new. Please don't tolerate bugs.

What's next

Though we will continue to treat performance as a high priority, we believe this release addresses most unresolved issues related to the scalability improvements of [email protected], with the notable exception mentioned above of allowing robust static analysis to scale to the largest repositories. If you continue to have performance problems, please file an issue.

Our next focus will be on reducing the complexity of setting up your workspace. As much as possible, gopls should "just work" when you open a Go file, independent of your configuration or which directories you have open.

Thank you to our contributors!

@adonovan @bcmills @cuishuang @cuonglm @dmitshur @hyangah @jba @lfolger @pjweinb @rsc @timothy-king @vikblom @vikstrous2

gopls/v0.13.0-pre.3

These are release notes for a prerelease version of gopls. v0.13.0 will be released soon, but please try the prerelease if you can!

go install golang.org/x/tools/[email protected]

This release fixes several bugs and mitigates a few performance regressions. It also somewhat reduces the latency and CPU cost of most operations, and includes a few small additional features.

Performance improvements

While [email protected] drastically reduced memory usage, several operations got around 50% slower due to additional I/O reading from the filesystem and time spent decoding indexes. This release optimizes those additional operations to (in most cases) achieve parity or better with the equivalent operation in [email protected]. Additionally, this release reduces total CPU while typing or performing common operations.

Faster code actions

This release includes a particularly large performance improvement in the evaluation of code actions (including formatting/goimports on save). In the past, there have been several reasons why this operation was expensive -- VS Code users may recognize the getting code actions from "Go" pop-up. This release fundamentally changes the way code actions are evaluated so that almost all of the work is pre-computed. As a result, formatting and adding or removing imports on save should be much faster.

Analysis performance

A notable exception to CPU performance parity with [email protected] is running static analysis. In this case, the additional cost incurred by [email protected] was not a regression, but rather the cost of analyzing many more packages to enable "deep" static analysis (see "Improved static analysis" in the [email protected] release notes.

In smaller repositories, the cost of this additional analysis is negligible -- analysis does not run until you stop typing, and typically just re-evaluates the changed package. However, it was discovered that in large workspaces that import low-level packages with a very large API surface (such as a cloud provider SDK or proto library), certain quadratic factors involved with the encoding/decoding of analysis results can dominate the cost of analysis, and result in enormous resource consumption: overloading the CPU and exhausting all memory.

This release partially mitigates those quadratic factors, significantly reducing their cost and limiting concurrency so that they do not exhaust all resources. However, fully eliminating these factors will require additional work to fix their quadratic nature. Until that is done, analysis may continue to be costly on certain repos, especially if "staticcheck" is enabled (because staticcheck does more deep analysis than the default set of analyzers).

In the meantime, a notification is added to make you aware when analysis is slow, and provide an update on the progress of indexing "deep" analysis results. Canceling this notification will cancel the ongoing analysis, but it will resume after the next change. If you don't want to see these notifications, you can set the new "analysisProgressReporting" setting to "false".
.

New Features

Highlight deprecated symbols

Deprecated symbols and packages are now marked as such. To turn off this feature, disable the "deprecated" analysis.

Stub methods to fix missing method errors

The "stubmethods" refactoring is now available as a quick-fix for errors related to missing methods.

Improvements to function extraction

Function extraction now puts context.Context parameters first in the resulting extracted function. See golang/go#60738 for details.

Improvements to the embeddirective analyzer

The embed directive analyzer now verifies the location of //go:embed directives, and provides a quick-fix to add missing "embed" imports.

Bug fixes

In addition to the performance fixes listed above, this release fixes a couple crashes. A full list of all issues fixed can be found in the gopls/v0.13.0 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new. Please don't tolerate bugs.

What's next

Though we will continue to treat performance as a high priority, we believe this release addresses most unresolved issues related to the scalability improvements of [email protected], with the notable exception mentioned of allowing robust static analysis to scale to the largest repositories. If you continue to have performance problems, please file an issue.

Our next focus will be on reducing the complexity of setting up your workspace. As much as possible, gopls should "just work" when you open a Go file, independent of your configuration or which directories you have open.

Thank you to our contributors!

@adonovan @bcmills @cuishuang @cuonglm @dmitshur @hyangah @jba @lfolger @pjweinb @rsc @timothy-king @vikblom @vikstrous2