On Mon, 3 Feb 2025 at 10:49, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > > > > > > > I'm in the process of writing my own C compiler for educational purposes. > > > Then look also into https://frama-c.com/ and > https://github.com/bstarynk/bismon > and https://nwcc.sourceforge.net/ and https://bellard.org/tcc/ > > > To this end, I have decided to integrate into my compiler my own C++ port ( > > https://github.com/johnythecarrot/mjolnir ) of the Rust crate Ariadne ( > > https://github.com/zesterer/ariadne ) which provides nice, fancy and > > readable > > diagnostics for use in compilers and the like. See the first link for an > > idea > > of how my library outputs diagnostics. > > > > I had the idea of perhaps contributing this diagnostics system to GCC in one > > way or another, under a flag perhaps, but considered it might be an > > unwelcome > > addition. I was told that there's no harm in raising it with the GCC > > developers. > > > > This message serves as a gauge of interest from the GCC developers for > > something of this kind. I am aware the current format of my diagnostics do > > not > > comply with the GNU Standards, and I'd therefore also like to politely ask > > for > > input on your suggestions on making it comply while retaining its > > cleanliness. > > > > I am the sole developer of Mjolnir and can therefore relicense it as > > necessary. Mjolnir still has a couple of issues to iron out and features to > > implement, such as multi-line span displaying. > > As far as I understand, GCC code needs to be GPL licensed with a copyright > assignment contract to the FSF. (See > https://gcc.gnu.org/legacy-ml/gcc/2006-12/msg00008.html > and https://arxiv.org/abs/1109.0779 ....)
No, this is incorrect. There's code in GCC under other licenses. It needs to be under a licence that is GPL *compatible*, not necessarily the GPL (e.g. see the zlib, libbacktrace and libsanitizer sub-directories). Third-party libraries do not need to have their copyright assigned to FSF. Even GCC code doesn't need to these days, see https://gcc.gnu.org/contribute.html#legal > regarding your fancy diagnostic system, consider working at the GIMPLE level > and > implementing it (at first) as an open source GCC plugin. > https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html > > Be aware that GCC extensions (e.g. your open source plugin) will use GCC > functions for diagnostics. > > By working on GIMPLE representation your code analyzer would be usable on most > of the languages having a GCC frontend. You probably want to extend the > existing > GCC static analysis infrastructure: > https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html > in relation with GCC link-time optimizations abilities. > > Regarding specifically C++ and its template machinery, you probably would have > issues in analyzing C++ template code. As far as I understand this is an > undecidable problem, so needs years of research (and could give you some PhD). > A naïve insight would be, for improving C++ template diagnostics, to try to > instanciate C++ template code (e.g. Boost libraries) with some guessed types. > I > have no idea of how to achieve this. > > Do you want to use machine learning techniques to improve your diagnostic tool > mjolnir? Perhaps some code from https://github.com/RefPerSys/RefPerSys/ (a GPL > licensed inference engine project) could be useful for your tool? These seems completely irrelevant, it's a library for formatting and displaying diagnostics, not for analyzing code and producing new diagnostics.
