\r\ngopls/v0.15.0-pre.3
\r\nThese are release notes for a prerelease version of gopls.\r\nv0.15.0 will be released soon, but please try the prerelease if you\r\ncan!
\r\ngo install golang.org/x/tools/gopls@v0.15.0-pre.3\r\n
\r\nThis release introduces "zero config" gopls, which is a set\r\nof heuristics allowing gopls to Do The Right Thing when you open a Go\r\nfile. We believe this addresses the two largest pain points we hear\r\nabout from our users: difficulty configuring multi-module repositories,\r\nand working on multiple GOOS/GOARCH combinations. However, this is a\r\nlarge change to the way gopls models your workspace, and the dynamic\r\nloading/unloading of builds may be surprising in some cases. Your\r\nfeedback on this new feature is greatly appreciated. See below for more\r\ndetails.
\r\nNew Features
\r\nSimpler workspace configuration and improved build tag support
\r\nThe headline feature of this release is a rewrite of gopls's logic\r\nfor associating files with build configurations that enables gopls to\r\ngive accurate answers when navigating almost any Go source file on your\r\nmachine.
\r\nMost features of gopls rely on type information, which comes not from\r\nthe file in isolation but depends on the relationship between the file\r\nand the other files in its package, and between the package and all its\r\ndependencies; this in turn depends on go.mod and go.work files. In\r\neffect, gopls needs to decide which go build command--which\r\nworking directory, package arguments, GOOS, GOARCH, build tags, and so\r\non--would cause each file to be processed by the compiler.
\r\nPrevious versions of gopls only allowed one build per workspace\r\nfolder, and users had to be careful to configure the right workspace\r\nroot and build environment. As a result, users often encountered\r\nconfusing error messages when they opened the wrong directory, or a file\r\nthat was tagged for a different operating system or architecture--the\r\ndreaded "No packages found" error. This situation was improved\r\nby the introduction of go.work files, but still required\r\nconfiguration and a preexisting understanding of the code being\r\nedited.
\r\nWith this release, gopls now allows multiple builds per workspace,\r\nand uses heuristics to automatically derive the set of active builds.\r\nGopls will ensure that an active build contains every module with an\r\nopen file in your workspace, adding new builds and GOOS/GOARCH\r\ncombinations as needed to cover files that don't match the host\r\noperating system or architecture.
\r\nFor example, suppose we had a repository with three modules:\r\nmoda, modb, and modc, and a\r\ngo.work file using modules moda and\r\nmodb. If we open the files moda/a.go,\r\nmodb/b.go, moda/a_windows.go, and\r\nmodc/c.go, gopls will automatically create three\r\nbuilds:
\r\n
\r\nIn some cases this may cause gopls to do more work, since gopls is\r\nnow tracking three builds instead of one. However, the scalability redesign we\r\nfirst announced in v0.12\r\nallows us to avoid most of this work by efficient caching in a\r\npersistent store.
\r\nSo, all gopls' navigation, query, analysis, and refactoring features\r\nshould work equally well in both files. Notably, you'll see compiler\r\ndiagnostics for the appropriate build in real time, making it much\r\neasier to make changes to cross-platform code.
\r\nPreview refactoring edits
\r\nRefactoring code actions now support resolving edits. This update\r\nenables features like code\r\naction previews within VS Code (triggered by Ctrl+Enter).
\r\n
\r\nTo take advantage of this new gopls feature, clients must register\r\nsupport via:
\r\n{\r\n\t"textDocument": {\r\n\t\t"codeAction": {\r\n\t\t\t"dataSupport": true,\r\n\t\t\t"resolveSupport": {\r\n\t\t\t\t"properties": ["edit"]\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n}\r\n
\r\nAnalysis & diagnostics
\r\n\r\n
\r\n... (truncated)
\r\n