Language Server Infrastructure

[nvarner]

Initial implementation of a language server, implementing document sync and supporting the document symbols request (in VS Code, enables the Overview pane and symbol search).

• I saw that .vscode is in the .gitignore. However, .vscode/launch.json and .vscode/tasks.json are valuable for testing the language server extension. I copied my settings into .vscode-template for now; is there a more preferred approach?
• I noticed that the repo doesn't have a license (except for the /editor/code/zls directory). Is this project intended to be closed source?

[maxsnew]

Asking Yuchen to review. Do you have instructions on how to use it? E.g., in VSCode/emacs?

And we should add a LICENSE. MIT is fine with me and uncontroversial

[LighghtEeloo]

Overall, the pull request LGTM. The infrastructure looks promising, so I'd say we accept it and build upon it.

[LighghtEeloo]

Initial implementation of a language server, implementing document sync and supporting the document symbols request (in VS Code, enables the Overview pane and symbol search).

• I saw that .vscode is in the .gitignore. However, .vscode/launch.json and .vscode/tasks.json are valuable for testing the language server extension. I copied my settings into .vscode-template for now; is there a more preferred approach?
• I noticed that the repo doesn't have a license (except for the /editor/code/zls directory). Is this project intended to be closed source?

Directly addressing these:

• We've got two options: make .vscode/{launch,tasks}.json tracked under zls directory, or move zls out as its own repo and allow the configs to be tracked. If zls and zydeco are too intertwined we'll keep them as are; otherwise, I'd prefer to separate them. (You can reply to this above)
• It should be totally open source. Any recommended license? MIT seems ideal and is widely used in academia. (Edit: Never mind just saw Max's comment lol)

[nvarner]

@maxsnew to run the VS Code extension during development, open editors/ in VS Code and launch "Run Extension" (defined in editors/.vscode/tasks.json). After the first run, this is bound to Ctrl+F5 on my system.

To release the extension on the VS Code Marketplace, the zls binary would currently have to be manually cross-compiled and copied into the VS Code extension for each OS/architecture you want to support. If desired, this can be more automated with a build system; I've had success setting up GitHub actions to build and deploy a language server and extensions.

I'm not familiar with Emacs, but there is a plugin which I believe provides very good LSP support. You would have to compile zls, then tell lsp-mode where to find the binary.

[LighghtEeloo]

Nice work! We'll build our LSP on this once we figure out how to dump the type-checking results, probably after a few new features are implemented on the front end (a minimal module system, for example). Thank you for your contribution! Make any final changes you'd like, and when you feel ready, tell me to merge :)

[nvarner]

Should be ready to merge now. Thanks!