x/tools/gopls: gopls does not reset workspace/configuration if missing from the client

[h9jiang]

gopls version

master head, following experiment is based on commit 6efe0f4b404b25e02999c3e34db08771f855fc28

go env

NA

What did you do?

Locate semantic token information from gopls of a string or a number. Toggle feature noSemanticString or noSemanticNumber.

What did you see happen?

By default, number's token info is returned from the gopls, you can see semantic token type = number.

Then if I set "ui.noSemanticNumber": true, the semantic token info goes away. WAI

If I set the "ui.noSemanticNumber": false,, the semantic token info comes back. WAI

Set it to "ui.noSemanticNumber": true,, the token info goes away. WAI. Then if I comment this out. What I expect is, the semantic token information will come back. Because, no setting means default value "ui.noSemanticNumber": false,.

What did you expect to see?

As a result it does not come back.

Editor and settings

No response

Logs

I will focus on the last two workspace/configuration logs

Where I set it to true

[Trace - 5:26:49 PM] Sending response 'workspace/configuration - (14)'. Processing request took 0ms
Result: [
    {
        "ui.semanticTokens": true,
        "ui.noSemanticNumber": true,
        "ui.inlayhint.hints": {
            "assignVariableTypes": false,
            "compositeLiteralFields": false,
            "compositeLiteralTypes": false,
            "constantValues": false,
            "functionTypeParameters": false,
            "parameterNames": false,
            "rangeVariableTypes": false
        },
        "ui.vulncheck": "Off",
        "linkifyShowMessage": true
    }
]

Where I comment it out

[Trace - 5:27:44 PM] Sending response 'workspace/configuration - (16)'. Processing request took 0ms
Result: [
    {
        "ui.semanticTokens": true,
        "ui.inlayhint.hints": {
            "assignVariableTypes": false,
            "compositeLiteralFields": false,
            "compositeLiteralTypes": false,
            "constantValues": false,
            "functionTypeParameters": false,
            "parameterNames": false,
            "rangeVariableTypes": false
        },
        "ui.vulncheck": "Off",
        "linkifyShowMessage": true
    }
]

I think what happened is, when gopls saw "ui.noSemanticNumber": X, in the json, gopls will apply this X in memory. WAI.
But when gopls saw "ui.noSemanticNumber": X, is missing in the json, gopls do nothing. In this case, gopls should set the ui.noSemanticNumber = false because false is the default value.

@findleyr

[gabyhelp]

Related Issues

• x/tools/gopls: semantictokens are disabled #43353 (closed)
• x/tools/gopls: not returning semanticTokensProvider capability #54531 (closed)
• x/tools/gopls: semantic tokens appear to have broken since v0.13.2 #63415 (closed)
• x/tools/gopls: Enable semanticTokens when running gopls from the CLI #64884 (closed)
• x/tools/gopls: Missing defaultLibrary semantic token modifier for builtin constants #70219 (closed)
• x/tools/gopls: Semantic Highlighting for builtin `true` and `false` broken in 0.17.0 #70934 (closed)
• x/tools/gopls: gopls semantic token registration problems #48600 (closed)

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

[findleyr]

I agree this is a bug, but perhaps not one that is easy to fix.

The problem is that on didChangeConfiguration notifications, gopls makes a workspace/configuration request to the client with a specific scope URI set to the workspace folder. IIUC, the VS Code client will respond with the workspace settings.json.

Has that response already merged user settings.json? Or was user settings.json sent as the initializationOptions?

If the former, we should always clobber the existing options with defaults, and then apply the result of workspace/configuration. If the latter, we need to keep a copy of the original initializationOptions that can be overlaid with workspace options.

Also: in our workspace/configuration request we ask for the "gopls" section of configuration, but are tolerant of users sending us configuration without the "gopls." prefix. Therefore, some clients will send an empty response to "workspace/configuration", and so only work if we overlay the "initializationOptions" of the original "initialize" request.

In summary: something we're doing is certainly wrong, but any change to our current behavior is liable to be complicated, and break some existing users. Therefore, we are unlikely to be able to solve this problem soon.