Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a server in the compiler that serves information about the compilation #615

Open
andrewrk opened this issue Nov 16, 2017 · 22 comments
Labels
accepted This proposal is planned. enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Nov 16, 2017

This will not be LSP, but a custom protocol just for Zig. A third party project can act as a proxy between this and LSP for that use case.

This issue covers both the compiler process (e.g. zig build-exe --listen=-) acting as a server, as well as a meta-protocol exposed by the build system (i.e. zig build --listen=-). The latter will act as a multiplexer for the former.

Once the initial implementation of both of these is created, follow-up issues can be made for specific features.

@andrewrk andrewrk added this to the 0.3.0 milestone Nov 16, 2017
@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. labels Nov 16, 2017
@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@binary132
Copy link

binary132 commented May 2, 2018

Does it make sense to tie this to the self-hosting Issue (#89), or do you think separate pieces of the functionality required for LSP should be delegated into a pipeline of (caching?) components which perhaps the core compiler functionality would also rely on?

@andrewrk
Copy link
Member Author

My plan is to solve this only in the self-hosted compiler.

@bb010g
Copy link

bb010g commented May 18, 2018

I'd be interested in investigating the differences between the LSP and what the Dart analyzer (API spec) provides, as JetBrains is actually able to use Dart's analyzer to fully power their Dart support due to the different features provided. Additionally, it looks like you can shim Dart's Analysis Server API to provide the Language Server Protocol without too much trouble.

@andrewrk
Copy link
Member Author

I know @thejoshwolfe has some bones to pick with the language server protocol in particular. I think in the end we will likely support a custom protocol that is more powerful than LSP, and theoretically you could implement a proxy that consumes the former and provides the latter. Perhaps zig can support both.

@ghost
Copy link

ghost commented Oct 2, 2018

I know @thejoshwolfe has some bones to pick with the language server protocol in particular.

No matter what, this will make working with zig so much easier 🥇

  1. editor completion support but also the whole ecosystem

one more example:
really nice code navigation https://about.sourcegraph.com/blog/sourcegraph-is-now-open-source/

@andrewrk andrewrk added the frontend Tokenization, parsing, AstGen, Sema, and Liveness. label Feb 2, 2019
@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Feb 2, 2019
@andrewrk andrewrk removed the contributor friendly This issue is limited in scope and/or knowledge of Zig internals. label Mar 3, 2019
@andrewrk
Copy link
Member Author

andrewrk commented Mar 3, 2019

This isn't contributor friendly yet. Lots to solve before work on this begins.

@pavildon
Copy link
Contributor

pavildon commented Jul 5, 2019

@andrewrk is this your idea?: to have a language server implemented as a function in the std lib, so can be called from the build script. and then spawn the process with 'zig run-lsp ...args'. I think some basic methods can be implemented from the LSP spec with what zig have right now.

@andrewk
Copy link

andrewk commented Jul 5, 2019 via email

@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Aug 27, 2019
@ice1000
Copy link
Contributor

ice1000 commented Oct 4, 2019

I found this https://github.com/ice1000/intellij-zig
It looks promising

Maybe not, hasn't been updated for a while

@ice1000
Copy link
Contributor

ice1000 commented Oct 6, 2019

Because I'm busy. As an alpha-stage language, Zig is changing its syntax from time to time, while the IntelliJ plugin parsers zig code using its own parser (created by me).

@ice1000
Copy link
Contributor

ice1000 commented Oct 6, 2019

I haven't implemented complicated reference resolution, thus you cannot have cross-file jumps and type inference. Zig is really unfriendly for IDE due to the C-interop hacks (you can use C references, which requires your IDE to understand C. For a language server, you also need to provide C source information, while you have LLVM in the Zig compiler to make things easier).

@xackus
Copy link
Contributor

xackus commented Oct 23, 2019

Please be aware that for best results the language parser should be error tolerant.
https://code.visualstudio.com/api/language-extensions/language-server-extension-guide#error-tolerant-parser-for-language-server

Currently the JSON dumps @andrewrk suggested to use in #3429 are not generated in case of a compilation error.
I do not know the compiler internals, how feasible is error tolerance when generating the JSON dump in stage1 and stage2 compiler?

Also, I presume the JSON format isn't planned to drastically change in the self-hosted compiler, is that correct?
I would be happy to start writing the language server.
In what directory in the repo should the server code be placed?

@andrewrk andrewrk changed the title Implement language server protocol Implement a server in the compiler that serves information about the compilation Mar 8, 2022
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@matklad
Copy link
Contributor

matklad commented Oct 10, 2022

This will not be LSP, but a custom protocol just for Zig. A third party project can act as a proxy between this and LSP for that use case.

Two thoughts:

  1. consider building a custom library (with well-isolated pure-data shaped API) rather than an IPC protocol. LSP is all the rage nowadays, but better not to close the avenue for embedding the thing in process.
  2. +1 on not coding against LSP specifically. The design principle we use for API layer in rust-analyzer is a) being 100% rust-specific b) targeting hypothetical “perfect” client which takes full advantage of what we provide. That general API is then explicitly dumbed down to LSP’s capabilities.

@Jarred-Sumner
Copy link
Contributor

Jarred-Sumner commented Jan 5, 2023

The current state as of January 2023 when you try to autocomplete sockaddr_t (from #14209)

Zig

  1. Type std.os.sockaddr
  2. No completions appear. Data types don't either. Go-to definition doesn't help
out.mp4

Rust

When you use Rust, completions work relatively consistently. In-editor feedback reports when the wrong number of arguments are passed to a function. It doesn't take more than a second or two to update the red squiggly lines. This improves developer productivity.

socket.mp4

Go

It works pretty well, including go-to definition

out.mp4

@SuperAuguste
Copy link
Contributor

@Jarred-Sumner Keep in mind that this is the current state of completions in zls and not the current state of completions in Zig; the compiler server is not implemented yet.

@Jarred-Sumner
Copy link
Contributor

Jarred-Sumner commented Jan 6, 2023

@Jarred-Sumner Keep in mind that this is the current state of completions in zls and not the current state of completions in Zig; the compiler server is not implemented yet.

Sure, but it is the current state of autocomplete for developers using Zig. It's relevant for this thread because it is an infrastructure/tooling problem that seems difficult for zls to solve well alone. rust-analyzer describes itself as a "Rust compiler frontend for IDEs" and that is essentially what this thread proposes (except, for Zig).

@matklad
Copy link
Contributor

matklad commented Feb 10, 2023

Some high-level thoughts on how one could actually do this:

https://matklad.github.io/2023/02/10/how-a-zig-ide-could-work.html

@andrewrk
Copy link
Member Author

Thank you for sharing! This dives a bit deeper than my own musings on the topic, so I found it quite insightful.

If you think about IDE support for the first time, a very tantalizing idea is to try to lean just into incremental compilation.

Guilty as charged 😅 and excellent points thereafter. Although I do think that may be a nice starting point - especially with some of the upcoming compilation speed enhancements that I have in mind.

@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
winterqt added a commit to winterqt/zig that referenced this issue Sep 15, 2023
This reverts a part of 7cc4a69, and
fixes ziglang#16376.

While the "correct" behavior on dumb terminals is still to be determined,
this is arguably a major regression from 0.10.0 to 0.11.0, leaving users
of various tools and CI platforms without any useful build logs.

This change mirrors the behavior of basically every other compiler out
there, which is to just not color the output (done implicitly in `std.io.tty`).

Of course, the idea for machine-readable compiler errors still has
merit, and with things like the to-be-implemented Zig compiler
server [0] and ZLS, there are just better ways to go about it than to
print somewhat useless error messages that a good portion of users will
see.

[0]: ziglang#615
winterqt added a commit to winterqt/zig that referenced this issue Sep 15, 2023
This reverts a part of 7cc4a69, and
closes ziglang#16376.

While the "correct" behavior on dumb terminals is still to be determined,
this is arguably a major regression from 0.10.0 to 0.11.0, leaving users
of various tools and CI platforms without any useful build logs.

This change mirrors the behavior of basically every other compiler out
there, which is to just not color the output (done implicitly in `std.io.tty`).

Of course, the idea for machine-readable compiler errors still has
merit, and with things like the to-be-implemented Zig compiler
server [0] and ZLS, there are just better ways to go about it than to
print somewhat useless error messages that a good portion of users will
see.

[0]: ziglang#615
@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. accepted This proposal is planned. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
None yet
Development

No branches or pull requests

11 participants