TypeId differs between builds

[MageSlayer]

Hi

I am getting strange inconsistencies between type_id results between crate compilations.
Please see attached test.
Tested in Rust Nightly:

 rustc --version
rustc 1.37.0-nightly (5d8f59f4b 2019-06-04)

To reproduce:

denis@denis-devuan:~/work/cargo-issue-1244$ LD_LIBRARY_PATH="/home/denis/work/cargo-issue-1244/AAA/a2/target/debug" make
cd z && cargo clean && cargo run
   Compiling x v0.0.1 (/home/denis/work/cargo-issue-1244/x)
   Compiling y v0.0.1 (/home/denis/work/cargo-issue-1244/y)
   Compiling z v0.0.1 (/home/denis/work/cargo-issue-1244/z)
    Finished dev [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/z`
TypeId { t: 10767430024512188608 }
TypeId { t: 10767430024512188608 }
TypeId { t: 10767430024512188608 }
cd AAA/a2 && cargo clean && cargo build
   Compiling x v0.0.1 (/home/denis/work/cargo-issue-1244/x)
   Compiling y v0.0.1 (/home/denis/work/cargo-issue-1244/y)
   Compiling a2 v0.0.1 (/home/denis/work/cargo-issue-1244/AAA/a2)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s
cd AAA/a && cargo clean && cargo run
    Updating crates.io index
   Compiling cc v1.0.37
   Compiling x v0.0.1 (/home/denis/work/cargo-issue-1244/x)
   Compiling y v0.0.1 (/home/denis/work/cargo-issue-1244/y)
   Compiling libloading v0.5.1
   Compiling a v0.0.1 (/home/denis/work/cargo-issue-1244/AAA/a)
    Finished dev [unoptimized + debuginfo] target(s) in 2.09s
     Running `target/debug/a`
TypeId { t: 10767430024512188608 }
TypeId { t: 10767430024512188608 }
AAA/a1 error tid TypeId { t: 10767430024512188608 }
AAA/a2 error tid TypeId { t: 10767430024512188608 }
AAA/a3 error tid 10767430024512188608
TypeId { t: 10767430024512188608 }
a2 TypeId { t: 10767430024512188608 }
denis@denis-devuan:~/work/cargo-issue-1244$ cd t
denis@denis-devuan:~/work/cargo-issue-1244/t$ cargo run
    Updating crates.io index
   Compiling cc v1.0.37
   Compiling x v0.0.1 (/home/denis/work/cargo-issue-1244/x)
   Compiling y v0.0.1 (/home/denis/work/cargo-issue-1244/y)
   Compiling a2 v0.0.1 (/home/denis/work/cargo-issue-1244/AAA/a2)
   Compiling libloading v0.5.1
   Compiling t v0.0.1 (/home/denis/work/cargo-issue-1244)
    Finished dev [unoptimized + debuginfo] target(s) in 1.75s
     Running `/home/denis/work/cargo-issue-1244/target/debug/t`
TypeId { t: 9299883569939456434 }
TypeId { t: 9299883569939456434 }
AAA/a1 error tid TypeId { t: 9299883569939456434 }
AAA/a2 error tid TypeId { t: 9299883569939456434 }
AAA/a3 error tid 9299883569939456434
TypeId { t: 9299883569939456434 }
a2 TypeId { t: 9299883569939456434 }

cargo-issue-1244.tar.gz

[Centril]

Marking as a possible soundness hole until shown otherwise.

[nagisa]

Not a rustc bug and I think not a soundness bug either.

When compiling from t, cargo specifies a different metadata hash than when compiling some other way:

# when compiling from `t`
     Running `rustc --crate-name x x/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=ba89e226349d96d7 -C extra-filename=-ba89e226349d96d7 --out-dir /tmp/cargo-issue-1244/target/debug/deps -C incremental=/tmp/cargo-issue-1244/target/debug/incremental -L dependency=/tmp/cargo-issue-1244/target/debug/deps`
# when compiling from `z`
     Running `rustc --crate-name x /tmp/cargo-issue-1244/x/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=2b52060268f81743 -C extra-filename=-2b52060268f81743 --out-dir /tmp/cargo-issue-1244/z/target/debug/deps -C incremental=/tmp/cargo-issue-1244/z/target/debug/incremental -L dependency=/tmp/cargo-issue-1244/z/target/debug/deps`

TypeId changes depending on this flag. Given

fn type_of<T:'static>(t: T) -> std::any::TypeId {
    std::any::TypeId::of::<T>()
}

fn main() {
    println!("{:?}", type_of(main));
}

The output changes as such:

$ rustc test.rs -Cmetadata=banana && ./test
TypeId { t: 3368847367085976146 }
$ rustc test.rs -Cmetadata=peach && ./test
TypeId { t: 540016422855212560 }

[MageSlayer]

@nagisa
I am not sure I got you right.

Are you trying to say that building the same crate from different paths should change TypeId?
Or you mean that it's cargo's fault?

My point is pretty concrete:

• how can I catch exceptions if calling Any::downgrade_ref won't work because of TypeId being different?

[ser-vasilich]

@nagisa
In rust docs: "A TypeId represents a globally unique identifier for a type".
As I see "unique", but not "globally".
From different folders and computers they will different. Right?

[pnkfelix]

(Note that, from when I've seen it on multiple projects in and outside of Rust, the word "globally", for better or for worse, does not cover the scope of Earth's globe itself. The scope of "globally" is, unfortunately, often quite dependent on the local context...)

[pnkfelix]

triage: Leaving nominated to discuss at T-compiler meeting. (I suspect I may need to add T-lang as well, but I'll wait until the meeting to do so.)

[nagisa]

Are you trying to say that building the same crate from different paths should change TypeId?

I don’t… know, but consider, for example, why the -Cmetadata argument exists at all. Cargo uses it to support multiple different versions of the same crate linked into the same project (among other things). In that case you do want TypeId to be different between two different versions of x.

Or you mean that it's cargo's fault?

I’m not sure why cargo uses a different -Cmetadata hash there when compiling the x crate, but if there is a bug, it is a cargo bug.

[MageSlayer]

@nagisa
In my concrete example there is just one crate containing Error type.
No different versions, no multiple dependencies.
I would expect TypeId for Error be the same.

/ No idea why -Cmetadata exists for.

I reported it to cargo repo.

[nikomatsakis]

So, I think the term global here means "global to within one binary". When you build a given binary, the type-id for the same type ought to be consistent for all uses of that. But if you have the same crate with distinct metadata, that is treated by the compiler as two different versions of the crate -- i.e., there are two types. This is like having two distinct cargo versions. I think that's what's happening here.

[MageSlayer]

Ok. Now I begin to see the idea.
But I still fail to see why the same crate gets distinct metadata.

Also you can easily see that library TypeId is also the same as main binary's, but still different between two compilations.

[pnkfelix]

triage: I believe this is not a bug, but rather the system operating as designed (that is, it is operating with an expected amount of freedom in terms of how it assigns type-id values). Leaving unprioritized (with intent to close) but also nominated so that lang team gets chance to confirm or contradict my aforementioned belief.

[MageSlayer]

It's kind of strange that nobody seems to notice the exact issue which sticks out of this "feature" - the inability to reliably handle exceptions crossing dynamic library boundaries.

[nikomatsakis]

@MageSlayer sorry for being slow to get back to you. The conclusion of this issue is that the current behavior -- at least from rustc's point-of-view -- is expected. Distinct metadata means distinct types.

It's true that we don't really have strong support for handling exceptions across dylib boundaries. That might be an interesting thing to try and address, but that would be a new feature, and hence best addressed by trying to write a Pre-RFC on internals to explore the problem and perhaps eventually through an RFC.

Thanks for filing the issue!