Re: LSP based on GCC
On Mon, 2023-05-29 at 17:16 -0300, Alexandre Oliva via Gcc wrote: > On May 17, 2023, Arsen Arsenović 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/
Re: Testing a patch
On Mon, 2023-05-29 at 15:09 +0200, Benjamin Priour wrote: > Hi, > > Regstrapping finally done for PR109439 - Spurious > -Wanalyzer-use-of-uninitialized-value tagging along > -Wanalyzer-out-of-bounds. > Now only a OOB warning is reported when necessary instead of OOB + > Use > of uninitialized value. > > Some tests in analyzer (out-of-bounds-*, realloc-5, pr101962) were > checking for the now removed use-of-uninitialized-value warning, and > therefore I fixed that. > > But now I'm confused since the documentation reads that to perform > regtesting, one should use make -k check, > and that's what I always use too, but because I fixed the above test > files, contrib/compare_tests obviously complains about them having > disappeared. > Does it mean regtesting failed ? If part of the purpose of a patch is the removal of certain tests, then if compare_tests is "complaining" about them disappearing, then arguably compare_tests is in fact verifying that the behavior of the patch matches the intended behavior. In this case, regression testing has effectively passed. > Can I submit the patch in its current > state or should I do something else before doing so ? Yes, please submit the patch in its current state, to gcc-patches, and CC me on it. Thanks Dave > Guess I would get feedback anyway if something's wrong. > > I figured I would send it here rather than to gcc-patches, as it's > more general than a discussion over a single patch. > > Thanks, > Benjamin >
