<p><a href="https://langdev.stackexchange.com/questions/915/how-would-you-design-a-compiler-upfront-to-be-both-a-compiler-and-a-lsp-server">I was originally thinking to design the compilier upfront as a compiler and LSP server as well</a>, but the answers there dissuaded me from making them share all code. But, I would still like them to share some code to make my life easier. So, what are some parts of the code that they can share?</p>

<language-design><compilers><language-server-protocol>
What parts of the code can be easily shared between the LSP and the Compiler?
CC BY-SA 4.0
2023-07-05T11:17:21.947Z
I'm still not convinced it is a good idea to separate compiler and LSP.  They still share the parser and a good part of compilation pipeline (without optimisations and backend). You want to see in LSP all the same compiler errors you see when compiling in normal mode, right?
SK-logic
CC BY-SA 4.0
2023-07-05T11:18:49.620Z
Yes but it seems much more complicated @SK-logic
Starship
CC BY-SA 4.0
2023-07-05T12:57:36.897Z
Why is it more complicated? You need a parser anyway - just use parsing techniques that are friendly to partial re-parsing. You need a typing pass, you need to resolve the identifiers, etc - in both LSP and compiler. Just make it possible to stop compilation after those passes, and allow incremental edits.
SK-logic
CC BY-SA 4.0
2023-07-05T14:40:19.847Z
Read the linked question
Starship
CC BY-SA 4.0
2023-07-05T15:27:05.380Z
I did (and I left an answer there), I still don't agree with any of the supposed complexities of such an architecture. Gavin Howard answer is mostly relevant to the case when you already have a compiler and want to retro-fit it as an LSP server. I imagine it can be problematic if the original compiler design is not flexible enough. But if you start from scratch, none of those points really matter.
SK-logic
<p>The information required by LSP is more detailed, and many of them can be reused by the compiler.</p>
<h2><code>textDocument/diagnostic</code></h2>
<p>Various syntax errors and compile-time errors in LSP can be reported using this endpoint.</p>
<p>In the compiler, when you execute through the command line, you also need to display this information again.</p>
<h2><code>textDocument/inlayHint</code></h2>
<p>When you do static type checking, record the type of each variable and display it using this endpoint.</p>
<h2><code>textDocument/signatureHelp</code></h2>
<p>Before using this capability, it is necessary to implement the ability to query token objects in the language according to offset or <code>(line, column)</code>,</p>
<p>This is also part of type checking, you need to know the actual type of each call.</p>
<h2><code>textDocument/references</code> and <code>textDocument/typeDefinition</code></h2>
<p>When you check whether the call is legal, cache the result of the check in the call symbol, and then reverse the query in the same way as before.</p>
<p>This can implement interfaces such as definition jumps, as well as record where functions or interfaces are called.</p>
<h2><code>workspace/semanticTokens/refresh</code></h2>
<p>After you verify the references of all symbols, you should know the attributes of each symbol, and you can update the semantic highlighting through this endpoint.</p>

CC BY-SA 4.0
2023-07-05T11:51:23.633Z
2023-07-05T11:51:23.633Z
Aster
# What parts of the code can be easily shared between the LSP and the Compiler?
Posted by: username_0 on 2023-07-05
[I was originally thinking to design the compilier upfront as a compiler and LSP server as well](https://langdev.stackexchange.com/questions/915/how-would-you-design-a-compiler-upfront-to-be-both-a-compiler-and-a-lsp-server), but the answers there dissuaded me from making them share all code. But, I would still like them to share some code to make my life easier. So, what are some parts of the code that they can share?
**Tags:** language-design compilers language-server-protocol
> **Comments:**
> **username_1**: I'm still not convinced it is a good idea to separate compiler and LSP.  They still share the parser and a good part of compilation pipeline (without optimisations and backend). You want to see in LSP all the same compiler errors you see when compiling in normal mode, right?  
> **username_0**: Yes but it seems much more complicated @SK-logic  
> **username_1**: Why is it more complicated? You need a parser anyway - just use parsing techniques that are friendly to partial re-parsing. You need a typing pass, you need to resolve the identifiers, etc - in both LSP and compiler. Just make it possible to stop compilation after those passes, and allow incremental edits.  
> **username_0**: Read the linked question  
> **username_1**: I did (and I left an answer there), I still don't agree with any of the supposed complexities of such an architecture. Gavin Howard answer is mostly relevant to the case when you already have a compiler and want to retro-fit it as an LSP server. I imagine it can be problematic if the original compiler design is not flexible enough. But if you start from scratch, none of those points really matter.  
---
## 1 answers
### Answer by username_2 on 2023-07-05. Score: 3 | Accepted answer
The information required by LSP is more detailed, and many of them can be reused by the compiler.

## `textDocument/diagnostic`

Various syntax errors and compile-time errors in LSP can be reported using this endpoint.

In the compiler, when you execute through the command line, you also need to display this information again.

## `textDocument/inlayHint`

When you do static type checking, record the type of each variable and display it using this endpoint.

## `textDocument/signatureHelp`

Before using this capability, it is necessary to implement the ability to query token objects in the language according to offset or `(line, column)`,

This is also part of type checking, you need to know the actual type of each call.

## `textDocument/references` and `textDocument/typeDefinition`

When you check whether the call is legal, cache the result of the check in the call symbol, and then reverse the query in the same way as before.

This can implement interfaces such as definition jumps, as well as record where functions or interfaces are called.

## `workspace/semanticTokens/refresh`

After you verify the references of all symbols, you should know the attributes of each symbol, and you can update the semantic highlighting through this endpoint.
---
