This bug is tangentially related to #51430 and subsequent investigation of the semantic token behavior. It seems that while many LSPs (intentionally) only send semantic tokens for certain elements or types of code object or simply do not support semantic tokens, gopls is simply broken. This simple fix may be a slight bandaid, but so far I haven't pinned down other lsps that are similarly broken in order to develop a broader theory of why, so far it just seems that gopls is a bit more finicky about it than most.

Reproduction steps

1. Start zed, using default config for go
2. open the highlights tree view and filter to only semantic
3. open a go file with some code in it
4. no highlights in the viewer. (you can also change the setting semantic_tokens to true and observe a complete lack of syntax highlights.

Current vs. Expected behavior

current behavior:

expected behavior (i have already fixed this):

Zed version and system specs

Zed: 0.229.0+nightly.2289.e79429b51b626e0120278b694351cd34a83386be
OS: MacOS 26.3
Memory: 16 GB
Arch: aarch64

Attach Zed log file

  "semanticTokensProvider": {
    "legend": {
      "tokenTypes": [
        "namespace",
        "type",
        "typeParameter",
        "parameter",
        "variable",
        "function",
        "method",
        "macro",
        "keyword",
        "comment",
        "string",
        "number",
        "operator",
        "label"
      ],
      "tokenModifiers": [
        "definition",
        "readonly",
        "defaultLibrary",
        "array",
        "bool",
        "chan",
        "format",
        "interface",
        "map",
        "number",
        "pointer",
        "signature",
        "slice",
        "string",
        "struct"
      ]
    },
    "range": true,
    "full": true
  },

Relevant Zed settings

No response

Relevant Keymap

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None