Re: [PATCH 00/17] RFC: New source-location representation; Language Server Protocol

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 26, 2017, Jim Wilson <jim.wilson@linaro.org> wrote:

> On 07/24/2017 01:04 PM, David Malcolm wrote:
>> * The LSP implementation is a just a proof-of-concept, to further
>> motivate capturing the extra data.  Turning it into a "proper" LSP
>> server implementation would be a *lot* more work, and I'm unlikely to
>> actually do that (but maybe someone on the list wants to take this on?)

> Apparently Alexandre Oliva has ideas on how to implement LSP by using
> gdb.  You two may want to compare notes.

*nod*

I thought GDB would be a better place for the server proper, because it
already knows how to deal with multiple translation units, how to
navigate the symbol tables in the presence of multiple contexts, how to
perform context-aware name completion and whatnot.

Current debug info is not enough to implement everything that's expected
of a language server, so we'd probably need a compile mode not entirely
unlike syntax-check (i.e., no actual code generation), but dumping
symbolic information about definitions (an extended subset of existing
debug info, since there's no object code to refer to, but there are
e.g. symbolic templates that don't appear at all nowadays), and either a
detailed summary of where tokens appear in sources, or something a bit
like preprocessed output, that contains even declarations brought from
header files, but perhaps without resolving preprocessor conditionals,
expanding macros or otherwise mangling actual sources.

I'm afraid this is as far as I got in the "design" that Richard Stallman
asked of me.  Lucky I knew what it was about because David had
introduced me to LSP back in March ;-)

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer