Formalize SVH stability for a specific release and target

[mzabaluev]

The Rust compiler does a pretty good job at generating strict version hashes that are stable for a given combination of the compiler revision, target, and the inputs, disregarding extraneous variation like the absolute path of the build directory. This can be confirmed by a test.

As outlined in this discussion, if this stability is committed to as a feature, it would enable stabilized use of Rust dylib crates in revision-controlled sandbox environments like Flatpak.

[comex]

I probably support this, but I'm confused what exactly you're trying to accomplish.

Let's say you build an executable, linking it against a Rust dylib "build-dylib", then ship it in a Flatpak together with a file "run-dylib".

Which of the following scenarios is yours?

1. build-dylib and run-dylib are the same file, but that file was built on a different machine from the executable.

That seems like the most obvious case, but then I don't see why you'd actually need SVH stability; at most it would be an issue for reproducible builds. (Reproducible builds are very useful, but I'm assuming they're not your only concern, since you seem to be portraying this as a hard requirement.) It seems like you'd only need a somewhat weaker guarantee: that if you build a dylib on machine A, then copy it to machine B which has the same version of rustc, you can use machine B to build crates against that dylib. In theory, that could be possible even if the dylib has a different hash than you'd get if you compiled the same source code on machine B.

2. build-dylib and run-dylib are built separately, but from the exact same crate source code on the exact same compiler version.

This scenario more precisely fits what you're asking for, but I don't understand why you would want to do this.

3. build-dylib and run-dylib are built separately from different crate source code.

For example, run-dylib could be an upgraded version of the crate containing a bugfix.

This would require SVH stability at a minimum, but also much more than that, so I'm assuming you're not asking for this.

[mzabaluev]

2. build-dylib and run-dylib are built separately, but from the exact same crate source code on the exact same compiler version.

This scenario more precisely fits what you're asking for, but I don't understand why you would want to do this.

It's needed because a Flatpak runtime (basically, a shared filesystem mounted into each app's sandbox) can be updated independently from applications using it. So run-dylib may be built for a different runtime revision, but as long as the crate source and the compiler version stay the same, it should be interchangeable with build-dylib.