Hi David, I appreciate your very nice words!
I wanted to clarify a couple points, as I'm unsure we're entirely on the same page. I am not proposing a new way to parse C++, nor am I using Rust. Mjolnir is written entirely in C++, and its only purpose is to take "labels" i.e, a span with an optional color and message, in order to display them in a visually pleasing and easy-to-parse (for humans) way. All it does is grab an already produced diagnostic and using my code, print it to the terminal. What I am proposing is an additional option (through a flag perhaps) for presentation to the user, specifically one using the visual layout demo'd on the Mjolnir GitHub page. It's nothing less or more than a diagnostics visualizer/renderer. Hence, my proposal is only visual in nature. If that is what you already knew and understood, then you may disregard my paragraphs above, I just wanted to double-check I was clear enough there. > How does mjolnir handle C++ template errors? I have not yet properly looked into this as my own compiler which Mjolnir was originally built for is a C compiler and will luckily not deal with this. I would be willing to try things out with regards to cleanly displaying such diagnostics, depending on if GCC would have a need for my code. > Have you looked into supporting SARIF as a machine-readable output format? I will be looking into it for my compiler, but it may be out of scope for my diagnostics visualizer library itself, I think. All that said, my concise question would be: is there any part of my diagnostics visualizer that would be a welcome addition to GCC? As far as licensing, API or implementation goes, I'm currently concerned primarily with the visual output, and not so much how it is achieved. I am not married to the idea of it necessarily using my library, I am willing to re-implement it as part of GCC, cherry-picking what we like and leaving out what we don't, or what is unnecessary. Also, while my Mjolnir project is likely unable to currently support much of the needs of a compiler with as wide a variety of diagnostics like GCC, it is only so because Mjolnir is about three days old, and I can expand its feature-set as GCC would need. Once again, I appreciate your kind words. Yours truly, Tuur On Monday, February 3rd, 2025 at 3:51 PM, David Malcolm <dmalc...@redhat.com> wrote: > On Mon, 2025-02-03 at 09:46 +0000, JohnyTheCarrot via Gcc wrote: > > > Dear GCC Developers, > > > Hi Tuur > > > I'm in the process of writing my own C compiler for educational > > purposes. > > 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. > > > That output looks great, thanks! There are some ideas in there I may > borrow for use in GCC - we're always looking for inspiration :) > > How does mjolnir handle C++ template errors? C++ compilers have an > alarming tendency to spam the user with multiple pages of output on > even simple errors, and I wonder if you've got any ideas on this. FWIW > we're working towards addressing this in GCC; see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253 > and an example here: > https://godbolt.org/z/xs4Gr6n6K > > > Have you looked into supporting SARIF as a machine-readable output > format? GCC supports capturing most of this "rich" diagnostic > information in its SARIF output; see e.g. > https://gcc.gnu.org/wiki/SARIF > > (or indeed, as a input format, for pretty output of SARIF log files?) > > > 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'm the maintainer of GCC's diagnostics subsystem, and since GCC 6 (?) > have been adding things like support for underlined ranges, fix-it > hints, and so forth. > > I confess that while I'm aware that there are some GNU standards for > diagnostics online somewhere, I've largely been ignoring them, to focus > on adding new features (what the kids today call "velocity") whilst > retaining compatibility within a >35 year old codebase, and to try to > > improve the user-experience; FWIW I've written a UX guide here for GCC > here: > https://gcc.gnu.org/onlinedocs/gccint/User-Experience-Guidelines.html > > In GCC 15 we've added some support for lines showing control flow, and > for colorized labels highlighting and contrasting different syntactic > elements; see e.g.: > https://gcc.gnu.org/wiki/cauldron2024talks?action=AttachFile&do=get&target=2024-Cauldron-diagnostics-talk.pdf > > and the "ASCII" art for buffer overflows added in GCC 14 here: > https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler#visualizing_buffer_overflows > > > 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. > > > Licensing (under a GPL-compatible license) isn't an issue so much as > implementation language. GCC has rather conservative build > requirements, since we must be buildable of a wide variety of old > machines with hundreds of configure-time variants. Although we > implement the very latest versions of C++ and have the beginnings of > Rust support, we implement all this in a subset of C++14 (and until > recently this was only C++11), and this subset has to be compatible > with a few other tools. > > So, sadly, implementing core GCC functionality in Rust isn't an option > at this point (I wish it were, but I don't see it happening any time > soon, I'm afraid). > > That said, I really like what you're doing. > > From am implementation point of view, GCC has a text_art::canvas class > for "painting" colorized text to a buffer with random access for output > to a stream, and a text_art::widget class for doing hierarchical > dynamic sizing of drawing elements. There's also a rich_location class > which is used by diagnostics that are doing anything "fancy", though > perhaps this could be refactored into an API similar to ariadne's (or > one of the similar projects). > > Hope this is constructive; thanks again for the links, and good luck > with mjolnir. > > Dave
