On Wed, 2024-08-21 at 10:34 +0200, Richard Biener wrote: > On Wed, Aug 21, 2024 at 2:01 AM David Malcolm <dmalc...@redhat.com> > wrote: > > > > On Tue, 2024-08-20 at 11:49 +0200, Richard Biener wrote: > > > On Thu, Aug 15, 2024 at 8:13 PM David Malcolm > > > <dmalc...@redhat.com> > > > wrote: > > > > > > > > Here's v3 of my patch kit for "libdiagnostics", which makes > > > > GCC's > > > > diagnostics subsystem available as a shared library; see: > > > > https://gcc.gnu.org/wiki/libdiagnostics > > > > > > So this is to make use of this from gas? > > > > One of the clients of the library would be gas, yes (although > > optionally, to avoid complicating bootstrap of binutils). > > > > However other clients would be possible, including those that are > > not > > under the "GNU toolchain" umbrella (provided that they can be > > linked > > against GPLv3 code). > > > > For example, I've been experimenting with Python bindings, which > > would > > allow Python scripts to reuse GCC's diagnostics code (e.g. for > > SARIF, > > fix-it hints, etc). I've also been experimenting with IDE > > integration > > (see PR 115970), and it would be nice if users of libdiagnostics > > got > > that "for free". > > > > Another example of client code is the sarif-replay tool in patch 7, > > as > > a sarif consumer (if nothing else, writing this has exposed various > > bugs in our existing SARIF-writing code). The analyzer's > > integration > > test suite generates 10s of thousands of .sarif files, so having > > tooling to work with them is "scratching my own itch". > > > > > Is the plan to move > > > sources (and dependences) to the toplevel then, possibly > > > building a static convenience lib for GCCs use? > > > > The problem with moving things from "gcc" to, say, a new > > subdirectory > > of the top level source directory is that our "gcc" subdirectory > > has a > > lot of support code that would also need refactoring/moving. Off > > the > > top of my head: > > - selftest framework > > - DejaGnu .exp stuff below gcc/testsuite/lib > > - C++11 support, such as our "make-unique.h" > > - libcpp: the big one: diagnostics uses libcpp > > - probably some configure/Makefile.in entanglements > > > > Fixing the above would be a major task. > > Yeah - I was wondering about dependences ... > > > So the patch kit punts on this by adding/moving stuff within "gcc" > > (and > > requiring an opt-in via --enable-libdiagnostics). > > OK, fair.
Thanks. > > > > > > Note I'm missing documentation (which is probably there > > > in the libdiagnostics.h header); an addition to sourcebuild.texi > > > might be nice at least and documenting --enable-libdiagnostics > > > in install.texi. Done (in install.texi) > > > > The libdiagnostics.h header has comments, but, yes, I should > > probably > > add docs similar to that of libgccjit.h (tutorial and API > > reference). > > I'll do that for the next iteration of the patch. > > > > Patch 2 of the kit documents --enable-libdiagnostics in > > install.texi. > > I'll add notes to sourcebuild.texi in the next iteration of the > > patch. > > > > > > Thanks; hope the above makes sense. > > Sure. Note I'm not super-happy with adding maintainance burden > on the GCC side for external users when the component is so > deeply interwinded with GCC internals. But I won't object ;) That's a fair concern. Note that the implementation of this is hidden behind an opaque API that only exposes a subset of its functionality, so external users *don't* see GCC implementation details like location_t, tree, or even diagnostic_context - so (I hope) things are reasonably well separated, and that gives enough room to evolve our diagnostics without breaking external users. I'm about to post v4 of the patch kit; I'm hoping to merge this for GCC 15. Dave
