x/tools/cmd/deadcode: suppress reporting of "marker" methods needed to implement "closed" interfaces (e.g. ast.Expr)

[paulhammond]

Go version

go version go1.24.4 linux/arm64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/dev/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/dev/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2946874249=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/dev/deadcode/go.mod'
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/dev/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I wrote the following minimal example of the “closed interface” pattern, as used in many Go applications (including, notably, the testing package):

package main

import "fmt"

type ClosedInterface interface {
        closed()
}

type Foo struct{}

func (w Foo) closed() {}

func main() {
        var w ClosedInterface = Foo{}
        fmt.Println(w)
}

What did you see happen?

When I ran deadcode against this command it reports:

main.go:11:14: unreachable func: Foo.closed

What did you expect to see?

In one sense this error is correct as Foo.closed is not called and is therefore unreachable. However if we remove that method then Foo no longer implements ClosedInterface and the program fails to compile. I think it would be an improvement if methods required for interface compliance were not reported as dead code.

[gabyhelp]

Related Issues

• x/tools/cmd/deadcode: unexported methods not reported as unreachable #65915 (closed)
• cmd/link: potential deadcode elimination opportunity of unused methods #38685 (closed)
• cmd/deadcode: no Go files ouput #65234 (closed)
• x/tools/cmd/deadcode: Deadcode not reported with different argument order in workspace #73652 (closed)
• cmd/link: Unused interface methods don't get gc'd #42421 (closed)
• x/tools/cmd/deadcode: add a way to treat exposed APIs as reachable #66073

Related Documentation

• Finding unreachable functions with deadcode > Example

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[adonovan]

I don't think it's a good use of author or reviewer effort to fix typos in function-local comments where the meaning is clear enough. By all means bundle such fixes into other CLs that touch that package, though.

[paulhammond]

@adonovan was that comment posted on the right issue? Not sure how it applies here but maybe I'm missing something?

[adonovan]

Apologies, that was meant for #75632.

[adonovan]

The deadcode tool reports functions that cannot be reached from any of the main packages provided to the tool. Often than means the function can simply be deleted, but not always, because the function may be used in ways that don't result in it being called, as in your example, or because it is called from another main package that was not part of the analysis. More analysis would be required to tell whether it is safe to delete the function entirely.

But I agree that marker interfaces such as "closed" in your example are a frequent source of noise in the results of deadcode, and it would make sense for it to recognize the pattern and suppress them from the results.

[FolkLoreee]

Hi, saw the help wanted label and I'm hoping to give this a shot.
To support this, I think we need these changes:

1. Identifying marker interfaces
2. Suppressing marker interfaces in deadcode cmd
3. Inclusion/Exclusion of marker interfaces when running deadcode

1. Identifying marker interfaces

We can identify funcs for Marker interfaces with these characteristics on the Function.Signature:

1. Is a method (i.e. has a receiver)
2. Is unexported
3. Has no params & results (other than the receiver)
4. Has an empty func body

2. Suppressing marker interfaces

We can mark whether or not to include marker interfaces similar to how we're marking generated files.
In this section where we're visiting every node in the package, we can use the checks in (1) for every method to mark the marker interface.
In this last section, before printing the list of functions, we can do the same step as -generated to filter out the marker interface methods.

3. Marker interface flag?

I think we should still allow users to choose whether or not to include the marker interface methods in the deadcode report.
Behavior-wise, I'm leaning towards following the -test and -generated flags, which follows the "inclusion" pattern:
if the flag is indicated in the command, then deadcode should include marker interfaces in the report.
But this means a change in the default behaviour of deadcode, ie.
as-is: without any flag, methods that implement marker interfaces are considered dead code.
to-be: without any flag, methods that implement marker interfaces are NOT considered dead code.

@adonovan pls lmk what you think
p.s. fairly new to OSS contributing. Sorry in advance for any inappropriate behavior or if I'm overstepping 😅

[adonovan]

Sorry in advance for any inappropriate behavior or if I'm overstepping 😅

Not at all! Thanks for your offer of help.

Your plan looks sound. I think we should change the default behavior to suppress marker methods by default, because that's what most users will want most of the time; those that don't have a way to get the old behavior.

[paulhammond]

I think you meant to assign @FolkLoreee? (I'd reassign myself but don't have permission)