Skip to content

CONCEPT Cited by 1 source

Build-error-driven fix loop

Definition

A build-error-driven fix loop is a migration-pipeline phase that treats the compiler's error messages as the specification for its next edits: run the compiler, parse the errors, apply targeted edits that dissolve each named error (add a missing import, insert a !!, introduce a parameter cast), re-build, repeat. The compiler is the oracle; the tool never has to re-implement what the compiler already knows.

Why it matters

Any multi-step code transformation has a long tail of small residual errors that are individually trivial but collectively costly. A purely generative approach (pre- compute every possible fix) duplicates a huge amount of compiler logic. A purely manual approach spends developer time on mechanical edits. The build-error-driven loop inverts the framing: don't predict the error, let the compiler report it, then fix what was reported.

Three properties that matter in practice:

  • Cheap to extend. New error patterns → new fix handler. No need to model the whole type system.
  • Safe by construction. Each fix is responding to a concrete compiler diagnostic, not a speculative analysis.
  • Compatible with broken intermediate states. Pairs naturally with metaprogramming on broken code — the post-fix tool sees source that was machine-emitted and is by construction unlikely to be clean on the first build.

Canonical wiki instance — Kotlinator phase 6

Meta's Kotlinator ends with exactly this loop as phase 6. The 2024-12-18 Meta post states the motivation plainly:

"In the course of doing our own conversions, we noticed that we spent a lot of time at the end repeatedly building and fixing our code based on the compiler's error messages. In theory, we could fix many of these problems in our custom postprocessing, but doing so would require us to reimplement a lot of complex logic that's baked into the Kotlin compiler. Instead, we added a new, final step in the Kotlinator that leverages the compiler's error messages the same way a human would."

Named fix classes in the post: "adding a missing import or inserting a !!". The loop runs on code that doesn't build yet — enabled by Meta's PSI-based metaprogramming (concepts/metaprogramming-on-broken-code), which does not require a green build to parse + analyse.

Contrast with compiler-plugin-based approaches

A compiler plugin hooks into compilation and can only fix things the compiler-internal APIs expose. A build-error loop runs outside compilation and can fix anything the error message points at — including multi-file edits a plugin can't reach in a single compile. The trade-off: plugins have richer type information; error-loop tools have broader edit reach.

Seen in

Last updated · 517 distilled / 1,221 read