David Malcolm <dmalc...@redhat.com> writes: > [...snip...] > 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?").
You mentioned 'cousin' tools in your original post, and I largely agree with your sentiment. Many parts of the job of an FE can be reused for many other purposes, evidently. Even beyond an LSP implementation. > Unfortunately the particular approach I came up with in (a) was > rejected by frontend maintainers, so I abandoned that part of the > work. I couldn't find the relevant messages. Mind sharing a message-id or archive link? > 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. AIUI, many editors (including Emacs' Eglot) also expect this (but I suspect many can leverage other methods of connecting too). ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to implement various bits of LSP functionality, such as handling multiple TUs. This sounds like a good idea to me (at least at a high level), as it could lead to the hypothetical GNU toolchain LSP implementation being partially language-agnostic (naturally, some things like candidate lists would still need language support, as well as documentation parsing, ...), which would be quite handy. Do you happen to have any memory of that? Thanks in advance, have a lovely evening. -- Arsen Arsenović
signature.asc
Description: PGP signature
