Results of the Grand C++ Error Explosion Competition (2014)

The D language compiler uses a technique I call &quot;poisoning&quot; which has greatly reduced cascading error messages. The idea is whenever an error is found in an AST node, the AST node is replaced with an &quot;error&quot; node. Any combination of an error node with another node is replaced with an error node. Error messages for error nodes are suppressed.<p>It works far better than attempting to repair the AST into some plausible state.<p>It&#x27;s analogous to the propagation of NaN values in floating point code.

I like to increment the most significant digit of my terminal history size every time I run into a compiler error that exceeds the previous value. On Saturday, it went up from 40k to 50k.<p>I laugh to hide my pain.

Some of the category descriptions are great, eg for &quot;Most lifelike&quot;:<p>Suppose you are given a task of adding some new functionality to an existing code base. You have been told that the guy who wrote it was “really smart” and that his code is of “enterprise quality”. You check out the code and open a random file in an editor. It appears on the screen. After just one microsecond of looking at the code you have lost your will to live and want nothing more than to beat your head against the table until you lose consciousness.<p>This entry could be that code.

Creative Computing magazine in the 1970&#x27;s had this kind of competition: most errors out of the smallest program, in any language.<p>Back that day, it was possible because parsers tried to repair bad input to try to keep going, in hopes of diagnosing as many real errors as possible, so as to reduce the number of iterations. Iterations used to be expensive: punching corrections onto cards, etc.<p>If the parser repairs bad syntax, it can cause more errors. If a repair involves insertion, there is a risk of getting into an infinite loop of diagnostics, even.<p>It&#x27;s kind of anachronistic to have people playing this with C++.<p>Why is this 2014? Did that error explosion competition die out?<p>Maybe tumblr isn&#x27;t where you find C++ people.

<i>Multiplier: 5.9 billion</i><p>That&#x27;s... several orders of magnitude larger than I&#x27;d have guessed.

Generally speaking, clang produces much clearer C++ compile errors than gcc. I can&#x27;t give any specific examples off the top of my head, but I&#x27;ve seen GCC emit hundreds of lines of inscrutable errors where clang spits out one line that tells you exactly what is wrong.

10 years afterwards and GCC still produces the huge error messages. It seems Clang is now smart enough to stop compiling after too many errors.

I&#x27;ve mostly become adept at traversing six mile long compile error crawls to find the bit in my code causing the STL&#x2F;Thrust complaint. clang is more legible for this than gcc. Still, I keep learning new patterns.

It might be interesting to see how much expansion could be obtained with Rust. The diagnostics can be verbose, and perhaps there&#x27;s some kind of self-reference that could produce a similar blowup, though I&#x27;m not familiar enough with the corners to say.

What&#x27;s the point in not showing the actual results? Is the expectation really to have a compiler handy just to browse the results

This is super interesting. I will do a 2024 edition.

Has anyone tried these code snippets on modern compilers and noted how much our error messages have improved?

I tried the first entry &#x27;Biggest error, category Anything&#x27; and was disappointed when the error message was really short. But I had made the &#x27;mistake&#x27; of using clang++, with g++ I get the crazy long error as promised.

The difference between an experienced C++ programmer and a C++ novice is that the novice regularly believes that his code <i>is broken beyond repair for eternity and has accidentally destroyed the compiler and most of the hard drive</i>, while the former just yawns at 5,000 lines of error messages and adds the missing semicolon.