#!stacks
"runtime.gopanic" && "methodsets.(*indexBuilder).build.func2:+12" ||
 "bug.Reportf" && "(*indexBuilder).build.func2.1:+1" || // off-by-one line due to telemetry bug
 "bug.Reportf" && "(*indexBuilder).build.func2:+32" ||  /* default case */
 "bug.Reportf" && "(*indexBuilder).build.func2:+28" /* method.Origin() != method */

Note that various cases of the refinement switch have been observed to have been reached.

Issue created by stacks.

        // Instantiations of generic methods don't have an
        // object path, so we use the generic.
        if p, err := objectpathFor(method.Origin()); err != nil {
            panic(err) // can't happen for a method of a package-level type
        } else {
            m.ObjectPath = b.string(string(p))
        }

First stack is here.

gopls version: v0.17.0-pre.2/go1.23.2 gopls flags: update flags: proxy extension version: 0.42.1 environment: Cursor darwin initialization error: undefined issue timestamp: Sat, 16 Nov 2024 15:11:16 GMT restart history: Sat, 16 Nov 2024 15:10:59 GMT: activation (enabled: true)

gopls stats -anon { "DirStats": { "Files": 5774, "TestdataFiles": 216, "GoFiles": 960, "ModFiles": 1, "Dirs": 516 }, "GOARCH": "arm64", "GOOS": "darwin", "GOPACKAGESDRIVER": "", "GOPLSCACHE": "", "GoVersion": "go1.23.2", "GoplsVersion": "v0.17.0-pre.2", "InitialWorkspaceLoadDuration": "1.603257166s", "MemStats": { "HeapAlloc": 318890328, "HeapInUse": 434987008, "TotalAlloc": 1358687472 }, "WorkspaceStats": { "Files": { "Total": 9784, "Largest": 4950165, "Errs": 0 }, "Views": [ { "GoCommandVersion": "go1.23.2", "AllPackages": { "Packages": 2191, "LargestPackage": 159, "CompiledGoFiles": 10309, "Modules": 322 }, "WorkspacePackages": { "Packages": 199, "LargestPackage": 54, "CompiledGoFiles": 1185, "Modules": 1 }, "Diagnostics": 0 } ] } }

Dups: yJIbcA 9nLJcw B-EmyA re0xQw VFXJYg MDN9RQ yO6-PA RUV5wg WIlwRw eH5YOA aDGiAQ GDWB-g

Comment From: jacksoom

[Info  - 7:38:35 PM] 2024/11/17 19:38:35 Created View (#1)
    directory=/Users/jacksoom/programer/pell/chain
    view_type="GoMod"
    root_dir="file:///Users/jacksoom/programer/pell/chain"
    go_version="go version go1.23.2 darwin/arm64"
    build_flags=[]
    env={GOOS:darwin GOARCH:arm64 GOCACHE:/Users/jacksoom/Library/Caches/go-build GOMODCACHE:/Users/jacksoom/programer/golang/pkg/mod GOPATH:/Users/jacksoom/programer/golang GOPRIVATE:github.com/0xPellNetwork/* GOFLAGS: GO111MODULE:on GOTOOLCHAIN:auto GOROOT:/Users/jacksoom/.goenv/versions/1.23.2 GoVersion:23 GoVersionOutput:go version go1.23.2 darwin/arm64
 ExplicitGOWORK: EffectiveGOPACKAGESDRIVER:}
    env_overlay=[]

[Info  - 7:38:36 PM] 2024/11/17 19:38:36 go/packages.Load golang/vscode-go#1
    view_id="1"
    snapshot=0
    directory=/Users/jacksoom/programer/pell/chain
    query=[/Users/jacksoom/programer/pell/chain/... builtin]
    packages=261
    duration=891.908667ms

panic: can't find path for func (github.com/cosmos/cosmos-sdk/x/authz.Authorization).ValidateBasic() error in github.com/cosmos/cosmos-sdk/x/authz

Comment From: jacksoom

gopls(server) output log

Comment From: jacksoom

go version go1.23.2 darwin/arm64 gopls version
golang.org/x/tools/gopls v0.17.0-pre.2

Comment From: jacksoom

The crash appears to be specific to this gopls version. After switching to version 0.16.2. works fine right now.

Comment From: findleyr

Thank you! We will fix this for the next prerelease. Very much appreciate the report.

Comment From: findleyr

@jacksoom could you please possibly include the full panicking stack? The panic message alone is not necessarily easy to track down.

Edit: see https://github.com/golang/go/issues/70418#issuecomment-2486096416; --@adonovan

Comment From: findleyr

@adonovan the panic here looks like the likely culprit: https://cs.opensource.google/go/x/tools/+/master:gopls/internal/cache/methodsets/methodsets.go;l=232;drc=1d5e334177335fd58b8eee6f809b3589bf7371aa

I can certainly imagine that some combination of aliases, generics, embedding, and importing could result in an interface method that has no objectpath. However, in that case the question is why didn't this reproduce with v0.16.2, as I don't think this logic has changed recently.

Comment From: adonovan

the panic here looks like the likely culprit:

Well spotted. We should probably always augment panic(err) calls with a distinct string to make these needles easier to find in the haystack.

Comment From: adonovan

This stack yJIbcA was reported by telemetry:

golang.org/x/tools/gopls@v0.17.0-pre.1 go1.23.3 linux/amd64 vscode (8)
golang.org/x/tools/gopls@v0.17.0-pre.2 go1.23.3 linux/amd64 vscode (5)

Comment From: adonovan

This is a real mystery. The error is:

panic: can't find path for func (github.com/cosmos/cosmos-sdk/x/authz.Authorization).ValidateBasic() error in github.com/cosmos/cosmos-sdk/x/authz

and the source is:

package authz // "github.com/cosmos/cosmos-sdk/x/authz"

import ( ... )

type Authorization interface {
    proto.Message
    MsgTypeURL() string
    Accept(ctx context.Context, msg sdk.Msg) (authz.AcceptResponse, error)
    ValidateBasic() error // <-- object of interest
}

Clearly objectpath.Encoder.For is getting all the way to the end without finding this method (types.Func) in the "step 4" search, yet there's nothing obviously tricky about this case. The pointer comparison in the interface method check raises the question about whether Origin is needed in case of generics, but there are no generics here:

    case *types.Interface:
        for i := 0; i < T.NumMethods(); i++ {
            m := T.Method(i)
            if f.seenMethods[m] {
                return nil
            }
            path2 := appendOpArg(path, opMethod, i)
            if m == f.obj {                                                         // sound?
                return path2 // found interface method
            }

I am unable to reproduce the crash locally while navigating this source tree.

Comment From: gopherbot

Change https://go.dev/cl/631778 mentions this issue: gopls/internal/cache/methodsets: refine crash for missing object path

Comment From: adonovan

This stack 9nLJcw was reported by telemetry:

golang.org/x/tools/gopls@v0.17.0-pre.4 go1.23.4 linux/amd64 vscode (4)

Comment From: adonovan

The latest stack indicates a refinement: a local type without type args or params, most likely a local named type.

Comment From: adonovan

This stack B-EmyA was reported by telemetry:

golang.org/x/tools/gopls@v0.18.0-pre.1 go1.23.4 linux/amd64 vscode (1)

Comment From: adonovan

This stack re0xQw was reported by telemetry:

golang.org/x/tools/gopls@v0.17.1 go1.24.0 darwin/arm64 vscode-insiders (2)

Comment From: findleyr

@jacksoom why did you close this?

Comment From: adonovan

This stack VFXJYg was reported by telemetry:

golang.org/x/tools/gopls@v0.18.1 go1.24.0 darwin/arm64 vscode-insiders (7)

Comment From: adonovan

This stack MDN9RQ was reported by telemetry:

golang.org/x/tools/gopls@v0.17.1 go1.23.2 darwin/amd64 vscode (1)

This stack yO6-PA was reported by telemetry:

golang.org/x/tools/gopls@v0.18.1 go1.23.7 darwin/amd64 vscode (1)

Comment From: adonovan

I still have no idea what is happening here. I suspect objectPath.For is failing to find the method (we know it is a method), and reaching the error at the very end. Pushing to v0.20.

Comment From: adonovan

This stack RUV5wg was reported by telemetry:

golang.org/x/tools/gopls@v0.18.1 go1.24.0 darwin/arm64 vscode (1)

Comment From: adonovan

This stack WIlwRw was reported by telemetry:

golang.org/x/tools/gopls@v0.19.0 go1.24.4 darwin/arm64 other (3)

Comment From: adonovan

This stack eH5YOA was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.3 windows/amd64 vscode (4)

Comment From: adonovan

This stack aDGiAQ was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 darwin/arm64 other (1)

Comment From: adonovan

This stack GDWB-g was reported by telemetry:

golang.org/x/tools/gopls@v0.20.0 go1.24.5 darwin/arm64 vscode (1)