This release fixes golang/go#65952, a crash in document highlighting when the cursor is in a return value for a function that has no results, such as the following example:
func f() { // <-- no results
return 0| // <-- cursor at '|'
}
Thanks very much to @patrickpichler who both reported and fixed this bug!
We're hopeful that once Go 1.23 is released, the opt-in automated crash reporting added in gopls v0.15.0 will increase the likelihood that these types of crashes are caught before they are released.
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/gopls@v0.15.0
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.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Bumps golang.org/x/tools from 0.14.0 to 0.19.0.
Release notes
Sourced from golang.org/x/tools's releases.
... (truncated)
Commits
7656c4c
go.mod: update golang.org/x dependencies5bf7d00
cmd/callgraph: add 'posn' template helper283fce2
x/tools: drop go1.18 support7f348c7
internal/versions: updates the meaning of FileVersions.38b0e9b
x/tools: add explicit Unalias operationsa6c03c8
x/tools: update telemetry import (new Start API)1f7dbdf
gopls/internal/cache: add debug assertions for bug report4d4e802
gopls/doc: address additional comments on workspace.mdabe5874
gopls/internal/analysis: add fill switch cases code actionfc70354
gopls/internal/test: add test for NPE in control flow highlightingDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show