At a lower level, symbols are mangled to include a crate identification hash. This is more of a way to allow multiple versions to coexist though, as the problem is already solved by that point.
At a lower level, symbols are mangled to include a crate identification hash. This is more of a way to allow multiple versions to coexist though, as the problem is already solved by that point.
1. Compile a library libA that references type T in CrateX.
2. Add a field to T, and recompile CrateX.
3. Compile an executable a.out that passes a T to libA.
Nobody bumped CrateX's version or recompiled libA. Won't this crash? Or does this produce a "different version" of CrateX and so it will refuse to link?
I used these sources:
// a.rs
#![crate_type = "lib"]
pub struct Foo { pub x: i32 }
// b.rs
#![crate_type = "lib"]
extern crate a;
pub fn foo() -> a::Foo { a::Foo {} }
// c.rs
extern crate b;
fn main() {
println!("{}", b::foo().x);
}
The field `x` from crate `a` was originally not there, and added after compiling crate `b`. The error when trying to compile crate `c` was: error[E0460]: found possibly newer version of crate `a` which `b` depends on
--> c.rs:1:1
|
1 | extern crate b;
| ^^^^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: crate `a` path #1: liba.rlib
= note: crate `b` path #1: libb.rlib pub struct S {
a: usize,
}
pub fn foo(s: &S) -> usize {
s.a
}
…as a dylib, then added another field to S and recompiled. I expected it to change the symbol names (as shown by nm), but it didn't. The metadata might be different (I don't know how to display it), but the dynamic linker doesn't know about that.However, Cargo will still ensure different versions of the same crate have different symbols, by passing its own hashes to rustc via -C metadata.
The metadata just contains info on all the types, and their hashes (or something like that), so if stuff doesn't match you'll know.
This is generally visible from the "expected type Foo but found type Foo" error, which will often mention you have two versions of the same crate.
Worth mentioning that unlike C++ or C Rust doesn't have a global name mangling scheme; so it is totally ok for two crates to have a toplevel struct Foo (unlike in C++ where you are forced to namespace them with uniquely-named namespaces). This has the side effect of it being totally ok to link two versions of the same crate together; and Rust will just complain if you try to mix the types.
Distinguishing between crates is done solely through their name and -C metadata values provided by Cargo.
Once crates are loaded by the compiler based on either their explicit path (via --extern) or by being a dependency of another dependency (and there the name and -C metadata prevent collisions), "two versions of the same crate" appears no different than "two different crates".
The Rust compiler tends to "index" information (e.g. turning strings into various IDs) as quickly as possible, so a lot more semantics are "by identity" than "by syntax", and that helps when multiple identities may share a name.
That includes compiling against already compiled crates, instead of header files you have serialized semantic types and functions, which all use proper identities to "name" anything they use in turn - you never have to be looking for a definition, or risk using the wrong one.