Re: LSP based on GCC

[David Malcolm <dmalcolm@redhat.com>]

On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote:
> Dear GCC developers,

[CCing Frank, re the systemtap LSP implementation]

Hi Eli

> Emacs 29, to be released soon, will come with a built-in client for
> the LSP protocol.  This allows to enhance important Emacs features,
> such as at-point documentation, on-the-fly diagnostic annotations,
> finding definitions and uses of program identifiers, enhanced
> completion of symbols and code, etc., based on capabilities of LSP
> servers.

Excellent.  Do you have a handy link to the specific LSP methods that
Emacs consumes?

> 
> The Emacs LSP client comes with support for many popular LSP servers
> OOTB and for all the programming languages supported by Emacs.
> However, all the available servers for C and C++ languages are based
> on Clang.  AFAIU, this is because GCC does not yet have its own
> implementation of the LSP.  I found this message posted to gcc-
> patches
> in 2017:
> 
>   https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html
> 
> which described the initial implementation of LSP in GCC, but I seem
> to be unable to find out what happened with that since then.
> 
> Are there plans for implementing the LSP in GCC?  If so, which GCC
> version is expected to have this included?

I wrote that prototype, but I haven't touched it since 2017, and I
already have more than enough other work, alas.  I'm happy to help if
someone wants to pick up the work and finish it.

That patch kit did several things:
(a) adds a new "on the side" representation of source code locations
(b) adds a JSON implementation to gcc
(c) implements an LSP server on a port, implementing only the
"textDocument/definition" method.

Not having quite enough source code location is a pet peeve of mine
within GCC's intermediate representation, as we lose a fair bit of
location information as we go from frontends to the tree/generic
representation (e.g. "exactly where was each brace?").  Unfortunately
the particular approach I came up with in (a) was rejected by frontend
maintainers, so I abandoned that part of the work.

The part of (b) for storing JSON trees in memory and writing them out
is in GCC's source tree; the JSON-parsing code isn't yet, but I have a
relatively up-to-date refreshed version of that code in one of my
working copies which I can post to the list if it will be helpful.

As for (c), doing it on a port is probably wrong, and working with
stdin/stdout seems a much better approach.


I note that systemtap recently gained an LSP server [1], where the
release notes say:

[begin quote]
* Added a "--language-server" option to stap, which switches it into
  an LSP server on stdin/stdout.  This allows users of a variety of
  editors to trigger symbol-completions and similar operations in
  context.  This code includes a small reusable jsonrpc server library
  implementation in C++.
[end quote]

The code in question appears to be in
https://sourceware.org/git/?p=systemtap.git;a=tree;f=language-server

though I'm not sure to what extent it's compatible with GCC (it's GPLv2
or later, but it seems to use exceptions; also I'm not sure which C++
dialect it uses - we can't go later than C++11 for our implementation
code).


> If there are no current plans for implementing LSP, I hope someone
> will work on that soon, given that Emacs can now use it, and because
> having a GCC-based LSP implementation will allow people to use their
> installed GCC as the basis for LSP features, instead of having to
> install yet another compiler.

Agreed.

BTW, in GCC 13 I implemented SARIF support for capturing diagnostics in
a standardized JSON-based format [2]; see e.g. the "Diagnostic
Serialization" slides in [3] which shows VS Code showing GCC
diagnostics with squiggly underlines.  Has anyone implemented SARIF
support for Emacs yet?  (FWIW I'm now on the SARIF technical committee)

Hope this is helpful
Dave


[1] https://lwn.net/ml/linux-kernel/ZEw5pdqi7y%2FjYqeA@elastic.org/
[2] https://sarifweb.azurewebsites.net/
[3]https://gcc.gnu.org/wiki/cauldron2022?action=AttachFile&do=get&target=2022-Cauldron-analyzer-talk.pdf