TypeID of `Box<Fn() -> ()>` inconsistent across crates

[MasonRemaley]

The TypeID of Box<Fn() -> ()> seems to be inconsistent across crates in both nightly and stable, I found a similar closed issue from a couple years ago and wasn't sure whether I should comment on that or file a new bug. I can recreate it consistently as follows:

typeid_issue/lib.rs:

pub fn check() {
    println!("{:?}", std::any::TypeId::of::<Box<Fn() -> ()>>());
}

typeid_issue/examples/example.rs:

extern crate typeid_issue;

fn main() {
    println!("{:?}", std::any::TypeId::of::<Box<Fn() -> ()>>());
    typeid_issue::check();
}

On my machine, cargo run --example example with the above project outputs two different TypeIds. The same thing doesn't happen for all types, e.g. Box<i32>s seem to work fine, and Box<Fn() -> ()> wrapped in a struct seems to work fine giving me a nice work around for now.

[Manishearth]

I don't think typeid is supposed to be consistent across compilations

[eddyb]

It looks like this is part of the same compilation, which would make it a bug.

[Manishearth]

Oh, my bad.

[MasonRemaley]

Yup, I should've made that a little clearer--I'm getting two different ids during the same run.

[eddyb]

On IRC @willcrichton pointed out that ProjectionPredicate (found in ExistentialBounds, which gets hashed wholesale) would hash differently in different crates, and that's indeed what's happening here: it contains Ty (which hashes as an arena pointer), DefId (which differs based on the crate you're seeing it from) and Name (which hashes as the index in the string interner).
The immediate solution here is to manually include those in, with Name hashed as its string form.

[Manishearth]

Sounds simple enough to fix then, @willcrichton are you working on this or should I pick it up?

[willcrichton]

@Manishearth I'll take a stab at it and post any troubles here.