From: Paul Smith <paul@mad-scientist.net>
To: "Alexandre Oliva" <oliva@adacore.com>,
"Arsen Arsenović" <arsen@aarsen.me>
Cc: David Malcolm <dmalcolm@redhat.com>, Eli Zaretskii <eliz@gnu.org>,
"Frank Ch. Eigler" <fche@elastic.org>,
gcc@gcc.gnu.org
Subject: Re: LSP based on GCC
Date: Tue, 30 May 2023 10:33:16 -0400 [thread overview]
Message-ID: <1852afca366ffcf4dcf17ec23e3db5c6134db6c5.camel@mad-scientist.net> (raw)
In-Reply-To: <orleh67v0z.fsf@lxoliva.fsfla.org>
On Mon, 2023-05-29 at 17:16 -0300, Alexandre Oliva via Gcc wrote:
> On May 17, 2023, Arsen Arsenović <arsen@aarsen.me> wrote:
>
> > ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to
> > implement various bits of LSP functionality, such as handling
> > multiple TUs.
>
> I recall advancing that suggestion, reasoning that GDB was capable of
> combining information from multiple translation units and of
> reloading debug information, which GCC doesn't.
I'm not sure this will work well. The information LSP servers need is
quite a bit more detailed (I believe) than what is found in the object
file debug sections.
Typically LSP servers generate their own index files, which are
completely separate from any compiler-generated output. When the
server starts it will proceed to parse and index the entire codebase
(which is unfortunately slow) then they try to keep that index updated
over time as code changes. So the LSP server will use the compiler
front-end to parse the code and keep information about symbols and
locations separately.
LSP servers are not intended to be limited to dealing with the code
that has already been compiled: not only do you want to be able to edit
code before it's been compiled, but you want to be able to query new
code as it's written in the editor, before it's even saved to disk.
I recommend that anyone who is interested in this project, examine the
LSP spec to understand what information the server needs to deal with:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
next prev parent reply other threads:[~2023-05-30 14:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 14:28 Eli Zaretskii
2023-05-17 15:46 ` David Malcolm
2023-05-17 17:10 ` Eli Zaretskii
2023-05-17 21:18 ` Arsen Arsenović
2023-05-29 20:16 ` Alexandre Oliva
2023-05-30 14:33 ` Paul Smith [this message]
2023-06-01 1:57 ` Alexandre Oliva
2023-05-18 14:28 ` Jason Merrill
2023-05-17 19:48 ` Paul Smith
2023-05-17 22:38 ` Ben Boeckel
2023-05-18 13:25 ` Paul Smith
2023-05-18 14:52 ` Ben Boeckel
2023-05-18 15:42 ` Paul Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1852afca366ffcf4dcf17ec23e3db5c6134db6c5.camel@mad-scientist.net \
--to=paul@mad-scientist.net \
--cc=arsen@aarsen.me \
--cc=dmalcolm@redhat.com \
--cc=eliz@gnu.org \
--cc=fche@elastic.org \
--cc=gcc@gcc.gnu.org \
--cc=oliva@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).