Skip to content(if available)orjump to list(if available)

Compiler Errors for Humans (2015)

Compiler Errors for Humans (2015)


·November 24, 2022


I'm reminded of these error messages from an Apple C compiler:

- "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"

- "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"

- "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"

Some of them are more helpful than others, but they are all rather human.


Too many errors on one line, make fewer.


I don't regret reading this comment before clicking the link


There was one that went something like "a typedef (or something) at this point was a complete surprise to me.'


Better than the infamous PHP error message made in Hebrew: T_PAAMAYIM_NEKUDOTAYIM


While those are funny, I'd hate using a compiler that actually gave me error messages like that.


Elm's error messages were the explicit inspiration for Rust's current error messages:


everyone opines about lovely rust error messages are. but in there is 'you really need to add lifetime annotations'. advice, which is followed, will result in days of mad refactoring, only to discover that was a _really bad plan_.

pure evil


I think they were an inspiration for most modern languages. Either directly or indirectly.


After shipping several production applications in Elm over the last five years... I can confirm that the development experience is an absolute joy.

With a compiler this helpful, and sub-second builds-on-save - you get really tight feedback loops.

I can't say enough good of it.


If you enjoy tight feedback loops and want something even quicker than "rebuild on save", you should try something like Clojure and hook up your editor to a REPL running in the background. Rather than "recompile the whole program on save", you can send small snippets to be evaluated in the live environment, updating your program on the fly :)


I was fairly happy doing REPL development with Scheme, and then I decided to give Common Lisp a try and I discovered what REAL REPL-driven development is.

The first time I changed some data representation from a defclass to a defstruct and SBCL asked me what I wanted to do with existing instances of the type was mindblowing.


In the early '80s at MIT, we learned the CLU [0] language. The wonderful aspect of that compiler is that when it hit a syntax error it would suspend compilation for a few dozen lines, or whatever it took to get past the blast radius of the error, and then continue compiling, looking for further errors. You'd see the error message on the faulty line, and then a "... resuming compilation here" message showing where it would start checking for more error messages.

You (obviously) wouldn't get a useable binary, but at least you'd see more than one error at a time, without the cascading sequence of errors you see in (most?) current compilers.



> Folks who prefer dynamically-typed languages are generally of the opinion that working with compiler error messages sucks.

I think a big factor here is dynamic languages can show concrete variable instantiations to help you understand what went wrong so it's less abstract e.g. the code `plus x y` might give the runtime error "x was 'abc' which is type String and not type Number" vs something more abstract and confusing like "x is type String and not type Number" that you tend to see in compile-time errors.

Are there any languages that give concrete variable instantiation examples as part of compile-time error messages? For instance, example values could be generated from the types, come from previous program runs, or supplied by the coder somewhere.

When errors get tricky, you tend to start plugging in concrete values or stepping through the program manually so compilers could definitely help more here.


In OCaml, if your pattern match is non-exhaustive, then the compiler generates example patterns that you aren't accounting for in addition to showing the missing type.

Here's an example:


Favorite experience with compiler errors: C++ in 2004 or so, when the errors were so voluminous and inscrutable that you had to install another program to massage them into something readable.


The first time I tried writing a C++ program with templates (very early on, like mid-late 90s), the compiler error messages were longer than the little program I was trying to write. It put me off on the language and the compiler so much that I went back to plain C and off into Perl and other languages, and never really got back to it.


I still wonder why editors don't understand line numbers on the CLI <editor> file:5

The editor should try to find if 'file:5' exist and open it if so, if it doesn't it should try to open 'foo' and then go to line 5.

Sounds sensible no? But I don't know any editor which does this.


> The editor should try to find if 'file:5' exist and open it if so, if it doesn't it should try to open 'foo' and then go to line 5.

Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default.

OTOH in Emacs you should be able to define a find-file-not-found-functions hook[0] and implement whatever fallback you want. I assume `emacs <file>` calls `find-file` after it's initialised the editor itself.



> Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default.

It gets even more fun on Windows! Giving a filename of `foo:5` can result in a file called `foo` with an alternate datastream called `5`.


> Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default

You're right, but even as an option I think it'd be nice.


Visual Studio Code does this (see "File links"): <>


I don't think it works from the CLI: code <file>:5 doesn't do what's expected.


You have to use the `-g` command line option: `code -g <file>:<line>`


That works in Emacs compilation buffers. You can also define custom patterns to match the output formats of different compilers.


It works with kwrite/kate/kdevelop.


JetBrains products do this for lots of stuff if you use the built in terminal to launch stuff or their runner.


vim does:

    vim file +5


But compiler error messages are file:5 so this isn't good enough.


That's why you have `:make` which uses `errorfmt` to populate your quickfix list, which is covered in the help `:h make`


Should a compiler also suggest applying the fix?

I'm working on my own toy language and wondering if simple, obvious errors (like the `map` -> `nap` typo from the article) should come with an "Apply fix? [y/N]" option when run interactively.


Maybe as an opt-in (mode or blanket approval), having to continue on every compiler error which has a fixer would be rather frustrating.

Clippy supports fixes, but will only apply them if `--fix` is supplied. It does not ask for individual case, the assumptions likely being that if you're running this opt-in you can probably do so with a clean working copy and revert whichever fixes you didn't want or are incorrect.

An other issue is if you're providing fixers for suggestions, the fixer has to be extremely reliable, not a 90% thing, because replacing broken code by possibly subtler broken code is not great.


On top of what others said, cargo is looking to further improve the fix workflow.

Right now, some errors offer fixes and these are marked machine-applicable. cargo-fix will apply these. The workflow was originally written for Edition migrations and has had little attention past that. Changes are applied in bulk and the worktree must be clean. There are known bugs and it isn't trusted to fix errors.

We want to slowly raise the visibility so we can collect feedback and gain more confidence in it. The first thing we did is tell users when there is something for cargo fix to do when getting compiler errors. Currently, this is limited to warnings and the nightly toolchain. I look forward to expanding this to more users (myself included).


Both Rust (via 'cargo fix') and Clang (via `clang-tidy -fix` have ways of doing this, I don't think I've seen someone offer this automatically/interactively though.

I don't think I've ever used them, but I've ABSOLUTELY used suggested fixes from LSP/rust-analyzer tools, which fit much more into my typical workflow. For things like match statements in Rust (which need to be exhaustive), I now have muscle memory to just write an empty match statement, and trigger the first LSP/r-a suggestion, which fills the match block with placeholder items.

I guess I see LSP as my "compiler in interactive mode" interface (even if that isn't EXACTLY true).


Discussed at the time:

Compiler Errors for Humans - - June 2015 (90 comments)


To actually get good errors in Elm you need to not use type inference and declare explicit types in lots of places. A big part of this is due to currying as any mistake in the number of parameters passed to a function is never type checked at the call site, but always when the accidental type collides with some other type.


I collect examples of systems that have helpful error messages. Here's a blog post (not mine) that praises error messages in React [1]. Any other examples?



I sometimes remember horrors of "undefined index of null" which are for new developers quite frustrating. Good job!