LSP Server support for GDShader

[AlfishSoftware]

Apparently, Godot Shading Language doesn't support external connection to LSP server like GDScript does.
Adding it would allow GDShader in external IDEs such as VSCode to provide language features such as completions, errors/warnings, etc. relying directly on Godot's implementation (instead of requiring authors to provide and maintain such implementation, which would be prone to errors, to be outdated, etc).

Would it be possible to add that? Would it be too difficult? Since the GDShader editor seems somewhat similar to GDScript editor, maybe whatever internal structures it uses could be somewhat prepared / easy to port for them to be served via LSP?

If possible / feasible, can someone add LSP server support to GDShader? It would allow VSCode extensions like the official Godot Tools and my own Godot Files (and any other IDEs compatible) to implement the LSP clients.
It would be bad to have the burden of maintenance (with regards to API updates) in the wrong place.

[AlfishSoftware]

From godotengine/godot-vscode-plugin#360 (comment) @DaelonSuzuka

What information would you actually get from a language server that you can't just as easily figure out in a client-only implementation? The current Godot version is the only thing I can think of.

I don't think a GDShader language server makes any sense, personally. Is it even possible for a single shader to be in more than one file?

While syntactic things are to be implement client-side, semantics are not. Things like what built-in variables and functions are available for completion are context-dependent. The language API really should be decoupled from the IDE extension. Where is a reliable GDShader API? The IDE extension should consult something from Godot at runtime, not rely on devs interpreting documentation (prone to errors or becoming obsolete) and pushing extension updates to keep in track with the current GDShader API. Since the Godot Editor can be literally just 1 executable file, the best thing to consult is an LSP server. Sure, things can be re-implemented client-side, but it's bad design to have the burden of following API updates on the extension when there's a better solution.

If an LSP server is not made, maybe a compiler can still be called and its output parsed (not sure if GDShader compiler is available via command-line). But this would allow just errors/warnings, not features such as context-dependent code completion (Intellisense). The editor compiler is already working internally in Godot, so the simplest is for it to share its already implemented state via LSP.

Considering this, the path that gives better results with less implementation work in the long-term is adapting it to do things the same way GDScript does, and have it simpler in the extension side. I don't know how much work that would actually be because I don't know the internals, but it should just depend on how similar GDShader editor's internal structures are to GDScript's. If the editors have been designed well and are similar enough, it should significantly reduce the necessary work; at least in comparison with redoing it all client-side.