x/tools/gopls: `//go:fix inline` not producing diagnostics/code actions at usages

[connorszczepaniak-wk]

gopls version

Build info
----------
golang.org/x/tools/gopls v0.19.1
    golang.org/x/tools/gopls@v0.19.1 h1:Yodhp3rnpnag60lVZrYPYbGMxTlTCIAj/B2Rv7AKuhA=
    github.com/BurntSushi/toml@v1.4.1-0.20240526193622-a339e1f7089c h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=
    github.com/fatih/camelcase@v1.0.0 h1:hxNvNX/xYBp0ovncs8WyWZrOrpBNub/JfaMvbURyft8=
    github.com/fatih/gomodifytags@v1.17.1-0.20250423142747-f3939df9aa3c h1:dDSgAjoOMp8da3egfz0t2S+t8RGOpEmEXZubcGuc0Bg=
    github.com/fatih/structtag@v1.2.0 h1:/OdNE99OxoI/PqaW/SuSK9uxxT3f/tcSZgon/ssNSx4=
    github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/typeparams@v0.0.0-20250218142911-aa4b98e5adaa h1:Br3+0EZZohShrmVVc85znGpxw7Ca8hsUJlrdT/JQGw8=
    golang.org/x/mod@v0.25.0 h1:n7a+ZbQKQA/Ysbyb0/6IbB1H/X41mKgbhfv7AfG/44w=
    golang.org/x/sync@v0.15.0 h1:KWH3jNZsfyT6xfAfKiz6MRNmd46ByHDYaZ7KSkCtdW8=
    golang.org/x/telemetry@v0.0.0-20250417124945-06ef541f3fa3 h1:RXY2+rSHXvxO2Y+gKrPjYVaEoGOqh3VEXFhnWAt1Irg=
    golang.org/x/text@v0.26.0 h1:P42AVeLghgTYr4+xUnTRKDMqpar+PtX7KWuNQL21L8M=
    golang.org/x/tools@v0.34.1-0.20250610205101-c26dd3ba555e h1:XnjOegqwH6kBJoae6InSGbIFPHcLtUT/Eq8HjrZKbmQ=
    golang.org/x/vuln@v1.1.4 h1:Ju8QsuyhX3Hk8ma3CesTbO8vfJD9EvUBgHvkxHBzj0I=
    honnef.co/go/tools@v0.7.0-0.dev.0.20250523013057-bbc2f4dd71ea h1:fj8r9irJSpolAGUdZBxJIRY3lLc4jH2Dt4lwnWyWwpw=
    mvdan.cc/gofumpt@v0.7.0 h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU=
    mvdan.cc/xurls/v2@v2.6.0 h1:3NTZpeTxYVWNSokW3MKeyVkz/j7uYXYiMtXRUfmjbgI=
go: go1.24.4

go env

AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/connorszczepaniak/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/connorszczepaniak/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/14/dl88pgbs11766nqnslc5ry8h0000gs/T/go-build730488648=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/path/to/project/go.mod'
GOMODCACHE='/Users/connorszczepaniak/go/pkg/mod'
GONOPROXY='github.com/Workiva'
GONOSUMDB='github.com/Workiva'
GOOS='darwin'
GOPATH='/Users/connorszczepaniak/go'
GOPRIVATE='github.com/Workiva'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.25.1/libexec'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/connorszczepaniak/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.25.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I put a //go:fix inline annotation on a deprecated function; exact verbiage is changed here but the shape is the same:

// Deprecated: Use the new function
// For example: newFunction(a, b, c)
// Or more simply: newFunction()
//
//go:fix inline

What did you see happen?

At usages, I don't see a diagnostic for the //go:fix inline nor the code action to inline it (though I do see the code action to inline the call, but I think all function calls get this). I do see the deprecation diagnostic at call sites.

What did you expect to see?

A diagnostic and a code action to inline the call.

If it matters, this Go module is very large (go list ./... tells me there are 1421 packages). The function in question also has 1362 usages.

Editor and settings

No response

Logs

Hmm, I tried to pass a -logfile in my nvim config of gopls to no avail... Can work on this more if it'll be helpful.

[adonovan]

Can you provide an example that reproduces the problem? The analyzer will not suggest fixes for calls where it knows the inlining algorithm cannot succeed, for example when making a cross-package call to a function whose body refers to non-exported symbols. There's no good way for the tools to indicate this information, so the error message is discarded and no fix is offered.

[connorszczepaniak-wk]

Yes, I did just manage to come up with a small example that reproduces:

Edit: updated to more minimal example

// main_test.go
package main

import (
	"testing"

	"example.com/test_project/pkg1"
)

// Neither of the following functions show inline diagnostics. If I omit the `t` input 
// to `OldFunction` and `NewFunction`, the diagnostics appear.

func TestSomething(t *testing.T) {
	pkg1.OldFunction(t)
}

func SomethingElse(t testing.TB) {
	pkg1.OldFunction(t)
}

package pkg1

import "testing"

//go:fix inline
func OldFunction(t testing.TB) string {
	return NewFunction(t)
}

func NewFunction(t testing.TB) string {
	return OldFunction(t)
}

[adonovan]

Strange... that did not reproduce the problem for me. I created the files in my working tree, and both gopls (in my editor) and the inline command were able to inline both calls to OldFunction:

tools$ cat gopls/main_test.go 
// main_test.go
package main_test

import (
	"testing"

	"golang.org/x/tools/gopls/pkg1"
)

// Neither of the following functions show inline diagnostics. If I omit the `t` input to `OldFunction` and `Build`,
// the diagnostics appear.

func TestSomething(t *testing.T) {
	pkg1.OldFunction(t)
}

func SomethingElse(t testing.TB) {
	pkg1.OldFunction(t)
}
tools$ cat gopls/pkg1/pkg1.go 
package pkg1

import "testing"

//go:fix inline
func OldFunction(t testing.TB) string {
	return NewBuilder().WithName("").Build(t)
}

type myBuilder struct {
	name string
}

func NewBuilder() *myBuilder {
	return &myBuilder{
		name: "",
	}
}

func (s *myBuilder) WithName(name string) *myBuilder {
	s.name = name
	return s
}

func (s *myBuilder) Build(testing.TB) string {
	return s.name
}
tools$ go run ./go/analysis/passes/inline/cmd/inline/main.go -fix -diff  ./gopls/
--- /Users/adonovan/x/tools/gopls/main_test.go (old)
+++ /Users/adonovan/x/tools/gopls/main_test.go (new)
@@ -11,9 +11,9 @@
 // the diagnostics appear.
 
 func TestSomething(t *testing.T) {
-	pkg1.OldFunction(t)
+	pkg1.NewBuilder().WithName("").Build(t)
 }
 
 func SomethingElse(t testing.TB) {
-	pkg1.OldFunction(t)
+	pkg1.NewBuilder().WithName("").Build(t)
 }
tools$ 

[connorszczepaniak-wk]

Yes, sorry about that, I am seeing diagnostics in my test module now -- perhaps I was too impatient before or something in my editor was wrong.

I've attempted to more faithfully recreate the exact code from the original module into my small test module and so far have had no luck reproducing the issue. Of note, I created some dummy packages to simulate some of the dependencies from the real function signatures. I wonder if a different import graph could affect things?

Also notably I haven't yet attempted to recreate the same imports/dependencies from the body of the Build function, could that affect the decision to suggest inlining?

Here's looking at it from a different angle: in the original module, in the package containing both the old and new functions, I can reproduce with some empty functions:

Whereas in my small test module, this produces diagnostics: