public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: Paul Smith <paul@mad-scientist.net>
Cc: "Arsen Arsenović" <arsen@aarsen.me>,
	"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: Wed, 31 May 2023 22:57:15 -0300	[thread overview]
Message-ID: <oredmw3pxg.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <1852afca366ffcf4dcf17ec23e3db5c6134db6c5.camel@mad-scientist.net> (Paul Smith's message of "Tue, 30 May 2023 10:33:16 -0400")

On May 30, 2023, Paul Smith <paul@mad-scientist.net> wrote:

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

It was well understood that augmenting debug information for LSP
purposes would likely be needed, and that GDB's ability to combine debug
information from multiple units would be advantageous to this end as
well.

An mode similar to thin LTO, that outputs internal representation along
with debug information, rather than compiling all the way to machine
code, was also in my mind.  That's similar to the indexing you mention.

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

ISTM there's some miscommunication here.  Using the compiler's parser
and debug information generator to index a project is no more
"compilation" than using the linker's ability to integrate multiple
translation units and the debugger's ability to take debug information
from them all to aid editing and other LSP activities amounts to
"debugging", it's just using each project's strengths to achieve the
desired goal.

-- 
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-06-01  1:57 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
2023-06-01  1:57         ` Alexandre Oliva [this message]
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=oredmw3pxg.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 \
    --cc=paul@mad-scientist.net \
    /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).