Error finding references on Go package names

[dadlerj]

Reproducable on sourcegraph.com: https://sourcegraph.com/github.com/kubernetes/apiserver/-/blob/pkg/server/serve.go#L17:9$references

Similar behavior occurs with external references, but the failure occurs on the xdef request, before it even gets to the xref request.

The API response (from the Chrome dev tools network tab) is:

[
    {
        "id": 0,
        "result": {
            "capabilities": {
                "hoverProvider": true,
                "definitionProvider": true,
                "referencesProvider": true,
                "documentSymbolProvider": true,
                "workspaceSymbolProvider": true,
                "implementationProvider": true,
                "xworkspaceReferencesProvider": true,
                "xdefinitionProvider": true,
                "xworkspaceSymbolByProperties": true
            }
        },
        "jsonrpc": "2.0"
    },
    {
        "id": 1,
        "error": {
            "code": 0,
            "message": "references object not found",
            "data": null
        },
        "jsonrpc": "2.0"
    },
    {
        "id": 2,
        "result": null,
        "jsonrpc": "2.0"
    }
]

[keegancsmith]

So the reason this doesn't work is that clicking on a package doesn't resolve to a specific location (so j2d doesn't work either). I don't think our implementation of references could necessarily work with it, but some special casing for package identifiers may make sense.

I'm unsure what you would want though? Imports? Our references code already uses a reverse import graph which would mean it would be easy to find the packages which reference a package.

[dadlerj]

Fair question — in my editor (Sourcegraph/VS Code), this works the way I expected:

(ms-vscode.go 0.6.78)

Though I obviously can't "go to definition" on this symbol.

[dadlerj]

Though even imports would be great (I know sourcegraph.com has a feature-flagged UI for this, though not sure how it's implemented)

[keegancsmith]

ok, then I would assume our implementation does work since it is a fork of go guru which vscode-go uses. Maybe go guru doesn't do an initial definition, while we do for some reason.

[sqs]

I got halfway into investigating this, will continue soon (probably next week).

I encountered another issue that also blocks this: https://github.com/sourcegraph/sourcegraph/issues/11189.

[ericliuche]

Looking to help out with this issue as a start off task