Skip to content

gopls/v0.14.0-pre.4

Pre-release
Pre-release
Compare
Choose a tag to compare
@adonovan adonovan released this 17 Oct 14:57
· 755 commits to master since this release

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:

inlinecall

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
inline_add inline_sub

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:

inline_unused

Improved support for go:embed directives

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

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.
image

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

"slog": checks for invalid structured logging calls.
image

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