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

LSP should communicate via socket, not standard input/otuput #5904

Closed
asterite opened this issue Sep 3, 2024 · 0 comments · Fixed by #5918
Closed

LSP should communicate via socket, not standard input/otuput #5904

asterite opened this issue Sep 3, 2024 · 0 comments · Fixed by #5918
Labels
enhancement New feature or request

Comments

@asterite
Copy link
Collaborator

asterite commented Sep 3, 2024

Problem

If you println at comptime, that gets mixed in the stdin/stdout stream of the LSP server and it ends up crashing it.

Happy Case

We should change our LSP code to communicate via sockets. The nargo lsp command should get the port to use. Then the extension should start communicating via a socket. We should still keep the old mode until users upgrade to the newest version of the extension.

Workaround

None

Workaround Description

No response

Additional Context

No response

Project Impact

None

Blocker Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@asterite asterite added the enhancement New feature or request label Sep 3, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Sep 3, 2024
github-merge-queue bot pushed a commit that referenced this issue Sep 4, 2024
# Description

## Problem

Resolves #5904

## Summary

I found out that writing to the error stream when connected to the LSP
client actually sends that output to the LSP output window ("Noir
Language Server") in our case so I chose to do that for comptime
println/print. Advantages:
- No more crashing of the LSP server on comptime println
- If you know it goes to that output you can actually see the output
without having to go to a terminal to run that code, so debugging
comptime will be pretty fast now
- (if you don't know the output goes there, it's fine too: at least the
LSP server doesn't crash 😄)


![lsp-comptime-println](https://github.com/user-attachments/assets/7d3ecaca-00fb-4c15-90a0-9868260ce7f5)

## Additional Context

Though the original issue was about using sockets to communicate with
the LSP client, I think we won't need that after all if comptime println
was the only issue (and I think most LSP servers use stdin/stdout for
communication because it's simpler).

Also: it would be better if this output showed up in a dedicated output
window, say "Noir Language comptime output" or something like that, but
only the LSP client can create those windows and write to them... so
implementing that would mean somehow communicating this data from the
server to the client (maybe a socket?), which is much harder to do... so
for now the output will have to show up like regular logs.

And a question: when the LSP server starts we have this code:

```rust
eprintln!("LSP starting...");
```

that shows up on the output window... should we remove it? It feel like
it was used to debug the server to know that it started, but I don't
know how useful it is now.

## Documentation

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant