Compiler-enforce CXX version matching between C++ and Rust

[nyurik]

As discovered in #1506, it is relatively easy to have a version mismatch between the cxx-bridge and the cxx crate in a complex project - i.e. cxx-bridge of one version generates the C++ code, and cxx crate of another version is built as part of Rust code. As anything else with Rust, I think this undefined behavior should be caught by the compiler if possible. FFI tends to be super error-prone, so reducing error surface would help.

[nyurik]

I have been thinking of the ways to enforce it, but if I understand it correctly, the bridge (c++) and crate (rust) exist on different sides of the language divide, which means the only way to catch this is via some linker magic. For example, given this declaration:

#[cxx::bridge(namespace = "rustutils")]
mod ffi { /*...*/ }

the cxx bridge would generate a dummy function, and the cxx::bridge rust macro would generate a call to that function

namespace rustutils {
  void $$expecting_cxx_bridge_version_1_0_157() {}
}

The function name should be descriptive enough so that if a linker shows missing symbol, it would be somewhat easy for developer to understand the problem. A similar approach could be used to verify the reverse - macro declaring a function and C++ calling it (I am not certain both are needed).

Lastly, I wonder if this approach would result in a (small) binary size increase, or if a linker could eliminate the empty functions. This should not really matter for the regular apps, but the embedded folks tend to worry about the binary size.