Semantic scopes may be killing Pyright

[tssm]

Describe the bug

Microsoft's Pyright language server dies shortly after it is launched. I checked how ALE integrated it and I don't see anything special

Environment

• neovim/vim version (nvim --version or vim --version): 0.4.4
• This plugin version (git rev-parse --short HEAD): 0.1.158
• This plugin's binary version (bin/languageclient --version): 0.1.158
• Minimal vimrc content (A minimal vimrc is the smallest vimrc that could
  reproduce the issue. Refer to an example [here][min-vimrc.vim]):

augroup filetype_python
    autocmd!
    autocmd BufReadPost *.py setlocal filetype=python
augroup END

let g:LanguageClient_serverCommands = {
    \ 'python': ['pyright-langserver', '--stdio'],
    \ }

• Language server link and version: 1.1.73

To Reproduce

Open and try to edit a Python file

Current behavior

Inmediately LanguageClient echoes: failed to parse semantic scopes: invalid type: map, expected a boolean. No diagnostics are shown and completion doesn't work

Expected behavior

Looks like Pyright is killed by the semantic scopes. Is there a way to disable them? I looked in the docs but I didn't find anything

Additional context

This is the LanguageClient log

#######
LanguageClient 0.1.158 
#######
09:29:53 WARN unnamed src/language_server_protocol.rs:1079 Failed to get initializationOptions: Failed to read file (/Users/tae/service-end-to-end-tests/.vim/settings.json)
09:29:53 ERROR unnamed src/language_server_protocol.rs:1221 LanguageClient: failed to parse semantic scopes: invalid type: map, expected a boolean
invalid type: map, expected a boolean
09:29:53 WARN unnamed src/language_server_protocol.rs:3903 Failed to get workspace settings: Failed to read file (/Users/tae/service-end-to-end-tests/.vim/settings.json)
09:29:53 WARN unnamed src/language_server_protocol.rs:2980 Failed to start language server automatically. invalid type: map, expected a boolean
09:29:53 ERROR unnamed src/rpchandler.rs:26 Error handling message: No path was found.

Message: {"jsonrpc":"2.0","method":"client/registerCapability","params":{"registrations":[{"id":"0482c96f-7096-4f78-8b4a-535d6c75576e","method":"workspace/didChangeWatchedFiles","registerOptions":{"watchers":[{"globPattern":"**/pyrightconfig.json","kind":7},{"globPattern":"**/mspythonconfig.json","kind":7},{"globPattern":"**/*.{py,pyi}","kind":7}]}}]},"id":0}

Error: No path was found.
09:29:56 ERROR unnamed src/rpchandler.rs:45 Error handling message: invalid type: map, expected a boolean

Message: {"jsonrpc":"2.0","method":"languageClient/handleTextChanged","params":{"bufnr":1,"filename":"/Users/tae/service-end-to-end-tests/tests/test_ifc_upload_large_001.py","languageId":"python"}}

Error: invalid type: map, expected a boolean

And this is Pyright's log

(node:2946) UnhandledPromiseRejectionWarning: Error: No path was found.
    at /nix/store/gc1vv71s8ipxravpz87fzij377xg5k2j-node_pyright-1.1.73/lib/node_modules/pyright/dist/vendor.js:2:113920
    at /nix/store/gc1vv71s8ipxravpz87fzij377xg5k2j-node_pyright-1.1.73/lib/node_modules/pyright/dist/vendor.js:2:114214
    at Immediate.<anonymous> (/nix/store/gc1vv71s8ipxravpz87fzij377xg5k2j-node_pyright-1.1.73/lib/node_modules/pyright/dist/vendor.js:2:114577)
    at processImmediate (internal/timers.js:456:21)
(node:2946) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:2946) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[martskins]

Yeah I think lsp-types has some differences with the protocol specification.

The specification indicates that documentHighlightProvider (in ServerCapabilities) is either a boolean or a map.

/**
	 * The server provides document highlight support.
	 */
	documentHighlightProvider?: boolean | DocumentHighlightOptions;

But lsp-types only supports a boolean there (see this). If you are happy to pick that up and open a PR I can probably help with it. Otherwise I'll see to do that later today, but we depend on lsp-types's maintainers merging that.

Thanks for reporting this

[martskins]

Seems like pyright is also not complying with the specification. The server is sending "workspaceSymbolProvider":{"workDoneProgress":true}, but workspaceSymbolProvider is defined in the specification as this:

	workspaceSymbolProvider?: boolean;

I already have a PR almost ready for lsp-types to support a map in cases like the documentHighlightProvider config. But I guess we should open an issue in pyright as well, to report that their server capabilities don't seem correct.

[tssm]

That was quick! Thanks! My Rust-fu is almost none, so I didn't know where to start.

I can open an issue in the Pyright repository once I can get a proper error from LC

[martskins]

If it helps, this is the message that we're getting from pyright on initialize.

{
    "jsonrpc": "2.0",
    "id": 0,
    "result": {
        "capabilities": {
            "textDocumentSync": 1,
            "definitionProvider": {
                "workDoneProgress": true
            },
            "referencesProvider": {
                "workDoneProgress": true
            },
            "documentSymbolProvider": {
                "workDoneProgress": true
            },
            "workspaceSymbolProvider": {
                "workDoneProgress": true
            },
            "hoverProvider": {
                "workDoneProgress": true
            },
            "documentHighlightProvider": {
                "workDoneProgress": true
            },
            "renameProvider": {
                "workDoneProgress": true
            },
            "completionProvider": {
                "triggerCharacters": [
                    ".",
                    "["
                ],
                "resolveProvider": true,
                "workDoneProgress": true
            },
            "signatureHelpProvider": {
                "triggerCharacters": [
                    "(",
                    ",",
                    ")"
                ],
                "workDoneProgress": true
            },
            "codeActionProvider": {
                "codeActionKinds": [
                    "quickfix",
                    "source.organizeImports"
                ],
                "workDoneProgress": true
            },
            "executeCommandProvider": {
                "commands": [],
                "workDoneProgress": true
            },
            "callHierarchyProvider": true
        }
    }
}

There you can see that workspaceSymbolProvider is an object, and that, per [the specification],(https://microsoft.github.io/language-server-protocol/specification.html) should be a boolean (or not be there at all).

[tssm]

I may be reading it wrongly but I think workspaceSymbolProvider may be a boolean or a WorkspaceSymbolOptions according to workspace symbols request:

• property path (optional): workspaceSymbolProvider
• property type: boolean | WorkspaceSymbolOptions

[martskins]

Hm it seems like the specification may have an error then? If you look for the interface ServerCapabilities, it's workspaceSymbolProvider field is defined as an optional boolean, it does not mention WorkspaceSymbolOptions.

[tssm]

Maybe I should start by creating an issue in the specification's repo

[martskins]

@tssm have you managed to open that issue? I can probably do that if you haven't.

[martskins]

Have opened an issue in the LSP repo and confirmed that it's an issue with the specification. Have already opened a PR in lsp-types to fix this, so once that gets merged I'll update the dependency here and it should fix this issue you are having.

[martskins]

Just merged the update for the lsp-types dependency (#1114), so this should now be fixed. I'll close it as it should be resolved, but feel free to re-open if you're still experiencing this issue.

Note that until we cut a new release (which should really be soon) you'll have to use (and build) the dev branch to see this fixed.

[tssm]

Sorry, life happened. Thanks for everything!