LLVM had multiple ABI conformance bugs in its implementation of int128, but clang had workarounds for these bugs that rustc lacked, causing interop problems. I wonder why they put workarounds in clang instead of fixing LLVM?!
This is a great example of one of the criticisms of LLVM, that language front ends must still implement processor-specific details themselves – iirc another example is struct layout.
For example, I remember that for many years, Rust would have to throw away part of its aliasing analysis because its annotations were too precise and would confuse LLVM’s optimizer. And so on. But it’s getting better.
Among other things, because it would probably break rust (and other projects that had come to rely on the mistaken representation). Interoperability bugs like this often end up fundamentally unfixable in practice and the community ends up having to embrace bifurcated standards.
It is probably entirely necessary to do it in this particular situation, but when people argue for no software ever breaking backward compatibility, they're arguing for more and more convoluted solutions like this. There's always a cost.
Toolchains are poster children for that genre, yeah. The ecosystems are too large and too interconnected to evolve in parallel. I mean, any one of LLVM, Rust and Clang are too large as a single project to implement a breaking change like this as a single event, trying to get them to do it in tandem just isn't going to happen. And even then there are uncounted other LLVM downstreams to worry about, all of whom need a story for how to migrate.
I just want to get the people who scream on HN about how software should never ever break backcompat under any circumstance, in a room with the people on this issue who are stunned by how convoluted this situation is, and get them to fight it out. Bonus points for when those people are the same person on different days.