public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: "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: Mon, 29 May 2023 17:16:44 -0300	[thread overview]
Message-ID: <orleh67v0z.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <86mt22sheq.fsf@aarsen.me> ("Arsen =?utf-8?Q?Arsenovi=C4=87?= =?utf-8?Q?=22's?= message of "Wed, 17 May 2023 23:18:45 +0200")

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.  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?

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.  But that was mainly a hunch that
it could work, not something based on extensive knowledge of GDB or LSP.
Details were all yet to be figured out.  I expected there'd be a need
for additional debug information to be emitted.  I wasn't sure how to
approach the issue of translation units that wouldn't compile or link
successfully yet.  There are many thorny issues to be sorted out.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

  reply	other threads:[~2023-05-29 20:16 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 [this message]
2023-05-30 14:33       ` Paul Smith
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=orleh67v0z.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=arsen@aarsen.me \
    --cc=dmalcolm@redhat.com \
    --cc=eliz@gnu.org \
    --cc=fche@elastic.org \
    --cc=gcc@gcc.gnu.org \
    /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).