x/tools/gopls: declare missing methods should (optionally) not shadow existing methods

[fastcat]

gopls version

golang.org/x/tools/gopls v0.21.0

``` Build info ---------- golang.org/x/tools/gopls v0.21.0 golang.org/x/tools/gopls@v0.21.0 h1:k8RlBm3ES+GVe+fbTSkzwKgarmNwN+6aDalb0T0xfag= github.com/BurntSushi/toml@v1.5.0 h1:W5quZX/G/csjUnuI8SUYlsHs9M38FC7znL0lIO+DvMg= 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/fsnotify/fsnotify@v1.9.0 h1:2Ml+OJNzbYCTzsxtv8vKSFD9PbJjmhYF14k/jKC7S9k= github.com/google/go-cmp@v0.7.0 h1:wk8382ETsv4JYUZwIsn6YpYiWiBsYLSJiTsyBybVuN8= github.com/google/jsonschema-go@v0.3.0 h1:6AH2TxVNtk3IlvkkhjrtbUc4S8AvO0Xii0DxIygDg+Q= github.com/modelcontextprotocol/go-sdk@v0.8.0 h1:jdsBtGzBLY287WKSIjYovOXAqtJkP+HtFQFKrZd4a6c= github.com/yosida95/uritemplate/v3@v3.0.2 h1:Ed3Oyj9yrmi9087+NczuL5BwkIc4wvTb5zIM+UJPGz4= golang.org/x/exp/typeparams@v0.0.0-20251023183803-a4bb9ffd2546 h1:HDjDiATsGqvuqvkDvgJjD1IgPrVekcSXVVE21JwvzGE= golang.org/x/mod@v0.30.0 h1:fDEXFVZ/fmCKProc/yAXXUijritrDzahmwwefnjoPFk= golang.org/x/sync@v0.18.0 h1:kr88TuHDroi+UVf+0hZnirlk8o8T+4MrK6mr60WkH/I= golang.org/x/sys@v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc= golang.org/x/telemetry@v0.0.0-20251111182119-bc8e575c7b54 h1:E2/AqCUMZGgd73TQkxUMcMla25GB9i/5HOdLr+uH7Vo= golang.org/x/text@v0.31.0 h1:aC8ghyu4JhP8VojJ2lEHBnochRno1sgL6nEi9WGFGMM= golang.org/x/tools@v0.39.1-0.20251205192105-907593008619 h1:NIdx9X+Z8lIV89t3Bs/bb4D/KTtHP4KYdUIFMiGlo6Y= golang.org/x/vuln@v1.1.4 h1:Ju8QsuyhX3Hk8ma3CesTbO8vfJD9EvUBgHvkxHBzj0I= honnef.co/go/tools@v0.7.0-0.dev.0.20251022135355-8273271481d0 h1:5SXjd4ET5dYijLaf0O3aOenC0Z4ZafIWSpjUzsQaNho= mvdan.cc/gofumpt@v0.8.0 h1:nZUCeC2ViFaerTcYKstMmfysj6uhQrA2vJe+2vwGU6k= mvdan.cc/xurls/v2@v2.6.0 h1:3NTZpeTxYVWNSokW3MKeyVkz/j7uYXYiMtXRUfmjbgI= go: go1.25.5 ```

go env

Details

```shell AR='ar' CC='gcc' CGO_CFLAGS='...' CGO_CPPFLAGS='' CGO_CXXFLAGS='...' CGO_ENABLED='1' CGO_FFLAGS='-O2 -g' CGO_LDFLAGS='...' CXX='g++' GCCGO='gccgo' GO111MODULE='' GOAMD64='v1' GOARCH='amd64' GOAUTH='netrc' GOBIN='' GOCACHE='/home/vscode/.cache/go-build' GOCACHEPROG='' GODEBUG='' GOENV='/home/vscode/.config/go/env' GOEXE='' GOEXPERIMENT='' GOFIPS140='off' GOFLAGS='' GOGCCFLAGS='...' GOHOSTARCH='amd64' GOHOSTOS='linux' GOINSECURE='' GOMOD='/dev/null' GOMODCACHE='/home/vscode/go/pkg/mod' GONOPROXY='github.com/ATIinc' GONOSUMDB='github.com/ATIinc' GOOS='linux' GOPATH='/home/vscode/go' GOPRIVATE='...' GOPROXY='https://proxy.golang.org,direct' GOROOT='/usr/local/go' GOSUMDB='sum.golang.org' GOTELEMETRY='local' GOTELEMETRYDIR='/home/vscode/.config/go/telemetry' GOTMPDIR='' GOTOOLCHAIN='auto' GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64' GOVCS='' GOVERSION='go1.25.5' GOWORK='/workspaces/.../go.work' PKG_CONFIG='pkg-config' ```

What did you do?

1. Define an interface (I) with more than one method (e.g. Foo() and Bar())
2. Define a struct (A) that implements some but not all of the interface's methods (e.g. just Foo())
3. Define a second struct (B) that embeds the first
4. Write a var _ Interface = (*B)(nil) assertion
5. Use the (vscode) Declare missing methods of I auto-fix

What did you see happen?

Stubs for all interface methods, both Foo() and Bar() are generated. The stub for Foo() has a comment pointing out that it shadows the method from A.

What did you expect to see?

I suspect that I am not alone in almost never wanting to have the shadowing methods generated. Especially since the auto-fix hint is to declare missing methods.

In practice, I'm sure generating all the shadowing stubs is sometimes desired, so perhaps two suggested fixes (one for all stubs, one for only the truly missing ones), or a gopls option to control the behavior? gopls options tend to not be very discoverable, so that seems like a less user-friendly solution.

Editor and settings

VSCode + vscode-go (Preview)

Logs

No response

[adonovan]

Yeah, I tend to agree that providing only the missing methods makes more sense. I looked over https://go.dev/cl/617619 and its attached issue and can't see any mention of this concern, despite it adding the logic to generate the comment that explicitly warns of shadowing. Perhaps @xzbdmw remembers.

[xzbdmw]

That "shadow" message comes from this cl https://go-review.googlesource.com/c/tools/+/544915, I keep that in the cross file change in my cl

[adonovan]

That "shadow" message comes from this cl https://go-review.googlesource.com/c/tools/+/544915.

Ah, so it does, and there's no particular discussion of the feature in that CL either. Perhaps @tttoad remembers why we add the shadowing methods.

[tttoad]

Ah, so it does, and there's no particular discussion of the feature in that CL either. Perhaps @tttoad remembers why we add the shadowing methods.

I hadn't considered this feature; perhaps I needed the shadow method at the time.Providing two suggested fixes would be a better approach.

[madelinekalil]

I have a draft CL that would omit shadowed methods: cl/738460 but can modify it to instead produce two separate quickfixes, one for the current behavior and one for omitting shadowed methods. I think this will also require a small change to the marker test framework since the @quickfix marker expects there to be exactly one quickfix for a given diagnostic.

[adonovan]

I have a draft CL that would omit shadowed methods: cl/738460 but can modify it to instead produce two separate quickfixes, one for the current behavior and one for omitting shadowed methods. I think this will also require a small change to the marker test framework since the quickfixmarker expects there to be exactly one quickfix for a given diagnostic.

Thanks. Before we go the trouble of supporting a second quick fix, are we sure that this warrants an option? The original poster says they never want the additional methods; @ttoad says they hadn't considered it but an option would be fine. Would anyone complain if we simply never generated the additional methods? As the OP said, the code action's name is "Declare missing methods".

Another possibility would be to generate the additional methods in a comment that the user could uncomment or delete as they prefer.

[madelinekalil]

I think since we already generate a comment indicating which method(s) are shadowed, the option of putting the shadowed methods in a comment is about the same amount of potential annoyance for users who don't want the shadowed methods at all. So I'm fine with just modifying the current quickfix to avoid shadowing existing methods.

[gopherbot]

Change https://go.dev/cl/738460 mentions this issue: gopls/internal/golang: don't shadow existing methods

[fastcat]

Thank you 😃