-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
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? |
My plan is to solve this only in the self-hosted compiler. |
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. |
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. |
No matter what, this will make working with zig so much easier 🥇
one more example: |
This isn't contributor friendly yet. Lots to solve before work on this begins. |
@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. |
You pinged the wrong account.
…On Fri., 5 Jul. 2019, 12:54 pm Patricio Villalobos, < ***@***.***> wrote:
@andrewk <https://github.com/andrewk> 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#615?email_source=notifications&email_token=AAAJIOXUZCHXUKAXEWGFXX3P52ZVDA5CNFSM4EECL752YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZINCKI#issuecomment-508612905>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAJIOWFIP67ELBFBJRWQVDP52ZVDANCNFSM4EECL75Q>
.
|
Maybe not, hasn't been updated for a while |
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). |
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). |
Please be aware that for best results the language parser should be error tolerant. Currently the JSON dumps @andrewrk suggested to use in #3429 are not generated in case of a compilation error. Also, I presume the JSON format isn't planned to drastically change in the self-hosted compiler, is that correct? |
Two thoughts:
|
The current state as of January 2023 when you try to autocomplete Zig
out.mp4RustWhen 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.mp4GoIt works pretty well, including go-to definition out.mp4 |
@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. |
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 |
Thank you for sharing! This dives a bit deeper than my own musings on the topic, so I found it quite insightful.
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. |
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
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
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.
The text was updated successfully, but these errors were encountered: