banner photo credit: kerut@pxhere (licensed as CC0)
From personal experience, I can attest that maintaining compiler infrastructure that builds on top of LLVM is hard over the long term. You try to compile something from a year ago with newest LLVM and find that it no longer works. The upstream LLVM developers make breaking API changes and it is the responsibility of downstream clients to fix their code accordingly.
In this essay, we make a broader argument: there are opportunities in analyzing changes to software components and either certifying compatibility or detecting breaking changes. Furthermore, many programming languages techniques (formal verification through testing and of course programming language design) can contribute to the important problem of reasoning about upgrades. We survey the role of contracts and discuss how to best determine the exposed API surface of a component.
Our vision is that there should be a range of tools that component developers can use to analyze their changes. These tools should produce output in a common machine-readable format. A skinny meta-tool can combine tools’ output and produce a breaking changes declaration for a new software version. Downstream developers can examine this declaration and rerun any tools they think appropriate (perhaps passing in more information about their particular use case).
All of this has only become viable in the past few years. The most important prerequisite is these vast component ecosystems that exist today. Continuous integration, scalable and incremental program analysis, and program-analysis-as-a-service will all help implement our vision.
It’s been fun to write this paper while in New Zealand, and I look forward to the next steps.