HN Explorer

7 comments

[ 3.3 ms ] story [ 22.6 ms ] thread
ChristianJacobs
Great news! As someone who's moving back to a C++ job after having worked with Rust for several years now, the error message parsing is one of the things I've been dreading the most... I'm still dreading it, but now sliiightly less.

Also, that interactive `-fanalyze`-output with the pointer visualisation looks super handy!

Happy to see there's still focus on the DX in GCC. C and C++ sorely needs it.

IshKebab
Wow I never thought I'd see GCC innovating with error messages!

I looked into using SARIF once before and found it's an enormous over-engineered design-by-committee spec, but I guess it's still better than regexes (do people really do that?).

rwmj
GCC has been innovating for a while with dmalcolm's -fanalyzer stuff.
whimblepop
SARIF is kinda nice for security-oriented linters imo, since lots of tools know how to speak it. It avoids lock-in that way, which is otherwise/previously pretty common, with every scanning tool using its own bespoke format.
account42
I'm unsure if the error message change is actually a good thing. IME the main problem with template error messages is not that they are unreadable but just the sheer amount of them you can get from a simple error which makes it hard to find the root cause among the log spam - making the trace even more verbose will not help that.
bluGill
Yeah, the example was trivially short. Only one candidate that didn't match. Last time I had a template error the complete compiler output was too large for my scroll back buffer. (4-5 errors, but each repeated in dozens of places). I really want to see the difference in more realistic cases.