Pointing at the error: compiler-style diagnostics in uutils coreutils

Pointing at the error: compiler-style diagnostics in uutils coreutils(uutils.org)

77 points by ingve 4 days ago | 11 comments

Handling errors in compilers has become the most interesting part of my job. If you do the math, most calls to compilers are error-yielding calls. So those calls really need to produce the best errors possible! (Maybe this is less true in LLM land, but certainly it was right before.) Tracking spans, doing extra algorithmic work, and exploring why the expectation failed in order to give a user the most-informative error possible is extra work on the main compute path. But it pays dividends: easily-diagnosable bugs and quick fixes present in the code itself. Tracking spans to point back to origin definitions, etc., always feel like plumbing work until you see the error that explains exactly what went sideways. And once you do, the errors that don't feel like a frustration you are trying to cast your net over.

noahbp 23 hours ago | |

>Maybe this is less true in LLM land, but certainly it was right before

I disagree:

I was tasked with rewriting a Python application in ucode for use on OpenWRT. It's a low-resource and dynamic language, and sufficiently JavaScript-like that Opus 4.8 couldn't write code without errors that were obvious with my LSP. The interpreter errors were often reported with the the correct line and column numbers, but with the incorrect code and a vague error message. I had to ask it to use my LSP and fix the warnings and errors, which led to it fixing a few dozen bugs.

Just the other day, Fable 5.1 still wrote a lot of code in Rust that had compiler errors. While I'm sure it could have fixed these errors if the Rust compiler also reported incorrect line numbers, columns, code, with a vague error message to boot, I saved a substantial amount of time and tokens because its error reporting is so comprehensive.

Specific and accurate error message reporting will always have the same high value that it does today. Error messages are far cheaper to generate than tokens.

chrystalkey 1 day ago | |

Can I ask which Compiler you are working on?

shakna 1 day ago |

Please run all of these through a TTS engine.

Yes, it is very helpful to have actually directed information. But the need to use a TUI to do it, bugs me. Not coincidentally, I use JAWS most of the time.

epage 1 day ago | |

While this is using ariadne for rendering, for annotate-snippets (the renderer for rustc) there is active work for a screen reader mode. This is being tracked at https://github.com/rust-lang/annotate-snippets-rs/issues/351

shakna 15 hours ago | | |

Yeah, I'm not really sure how to feel about the way they plan to handle it.

"Happy it exists at all" resonates. Most accessibility users find something inaccessible, sigh, and move on. Most of the time there is nothing we can do, and most of the time the complaint platform itself is inaccessible. We're taught not to complain.

But... The idea of a NO_GRAPHICS env var? I don't particularly like that. Its a hidden, unstandardised, global. To discover it exists, I have to first use the software in its inaccessible form - where I'd find it inaccessible, sigh, and move onto something else.

emilfihlman 1 day ago |

Cool innovation (actually is good and cool).

Do it after you have actually made the rust version work the same as the C version.

Insane to be adding complexity, breaking compatibility and introducing new bugs to software that needs to function correctly.

QuantumNomad_ 22 hours ago | |

> Insane to be adding complexity, breaking compatibility and introducing new bugs to software that needs to function correctly.

On one hand yes. On the other hand maybe adding this detailed error reporting will prove so useful to LLMs that it helps uutils adoption grow significantly, instead of uutils fading into obscurity while the world keeps running on the original coreutils.

a2ff6eeb0 22 hours ago | | |

AI would do better with a wordier textual description, rather than a 2d layout.