For a library author, how maintenance of a stable ABI would look like?

[HeroicKatora]

@kornel

And most importantly: the ABI from the source code can be exported to a text file, something like a Cargo.lock, but describing the binary interface of the crate. The tooling would warn when the source code differs from the "locked" ABI — on any supported target, not just the current host! This will catch unexpected ABI breaks at development time. Thanks to having lock files in version control, I would be able to easily and reliably compare ABI with previous versions of the library to offer accurate changelogs and backwards-compatibility information.

This seems like the hardest requirement with regards to tooling. I'd like to embed it into the binrary so that it can be loaded and checked by any dll-consumer downstream (and potentially to embed multiple versions of an API by not tying the types to static symbol names?). In fact, my dream tooling for dynamic linking would run full type-checking of the interface in a manner like the Rust compiler so that there is virtually no distinguishable difference between static and dynamic linking. Since not everyone wants that, I get that producing a separate interface description file is also desirable. This same file would then also serve as the declaration file in the consumer, but since it requires type analysis passes first it's not as simple as running include_bytes! on a path produced by a build script.