Releases: golang/tools
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/gopls@v0.14.0
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 gopls@v0.12.3. 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
Contributors
Assets 2
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/gopls@v0.14.0-pre.4
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 gopls@v0.12.3. 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
Contributors
Assets 2
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 gopls@v0.13.0-pre.3. Thanks to all who tested the prerelease!
go install golang.org/x/tools/gopls@v0.13.0
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 gopls@v0.12.x 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 gopls@v0.11.0. 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 gopls@v0.11.0 is running static analysis. In this case, the additional cost incurred by gopls@v0.12.x was not a regression, but rather the cost of analyzing many more packages to enable "deep" static analysis (see "Improved static analysis" in the gopls@v0.12.0 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 gopls@v0.12.x, 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
Contributors
Assets 2
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/gopls@v0.13.0-pre.3
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 gopls@v0.12.x 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 gopls@v0.11.0. 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 gopls@v0.11.0 is running static analysis. In this case, the additional cost incurred by gopls@v0.12.x was not a regression, but rather the cost of analyzing many more packages to enable "deep" static analysis (see "Improved static analysis" in the gopls@v0.12.0 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 gopls@v0.12.x, 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
Contributors
Assets 2
gopls/v0.12.4
This is a follow up to gopls@v0.12.3 fixing a crash in the new analysis driver, in the presence of certain invalid packages (golang/go#60952).
For more details, see the gopls/v0.12.4 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new.
gopls/v0.12.3
This release fixes a couple rare but significant performance regressions introduced in the v0.12.0 release.
Bug fixes
- Poor analysis performance on certain repositories (golang/go#60621): the first time a repository is analyzed, the new analysis driver loads data for open packages and all their dependencies. In v0.12.0, the naive recursion caused certain operations related to type information to be executed once per edge, not node, in the import graph. In some repositories with unusually large type information (e.g. hashicorp/terraform-provider-aws), this exhausted all memory. We have rewritten the recursion to process package types at most once per node.
- Missing fields and methods in autocompletion results (golang/go#53992): due to a change in v0.12.0, it became more likely that autocompletion would exhaust its time budget before all fields or methods had been collected. This release guarantees that autocompletion includes these critical completion items.
A full list of all issues fixed can be found in the gopls/v0.12.3 milestone.
To report a new problem, please file a new issue at https://go.dev/issues/new.
gopls/v0.12.2
This is an alias for the gopls/v0.12.1 release, and the gopls command reports its version as v0.12.1.
(It was created in the v0.12.1 release process as a defensive measure during an incident that we are investigating.)
Update (findleyr@): the incident in question was a failure to install "gopls@latest" due to a cached 404 in the sumdb. Many LSP clients install gopls@latest, so we cut v0.12.2 as a stopgap measure to ensure that installing gopls@latest continued to work.
Installing gopls@v0.12.1 eventually worked, after ~30m.
gopls/v0.12.1
This release fixes a few regressions/crashes in the v0.12.0 release:
- Unimported completion should use fuzzy matching (golang/go#60545).
- Fix a crash when method has receiver type
comparable(golang/go#60544). - Fix for documentHighlight on import paths (golang/go#60435 -- this was pre-existing).
- Clear vulncheck diagnostics when they are toggled off (golang/go#60574).
These are also summarized in the release milestone.