Add a type_id intrinsic

[alexcrichton]

This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).

[luqmana]

Won't this fail in stage0 since the intrinsic isn't snapshotted yet?

[alexcrichton]

Good catch. As a responsible contributor I always compile my code before submitting it!

[brson]

This looks really awesome. This hash routine should probably replace all our type hashing (which I understand is currently incorrectly hashing dids). Does anybody have a sense of whether a u64 is enough space to reasonably avoid collisions? It seems fairly small ...

@nikomatsakis Can you look at whether the region types are handled correctly here?

[nikomatsakis]

This is an interesting idea. Can this replace all uses of type descriptors? Put another way: if all we care about is identity, I guess it can.

[nikomatsakis]

It occurs to me that, since regions are erased from the hashed types, the methods like is() on Any are unsound unless the type T has the bound 'static. Also, we'll have to be awfully careful if we still do any monomorphic collapsing (i.e., the old type_use) -- was that removed?

[thestinger]

@nikomatsakis: I think trans pretends all lifetime parameters are 'static.

[thestinger]

This generates a single monomorphized instance:

fn foo<'a>(x: &'a int) -> &'a int {
    x
}

static FOO: int = 5;

fn main() {
    foo(&FOO);
    let x = 10;
    foo(&x);
}

[nikomatsakis]

@thestinger this is my point.

@alexcrichton I realize I didn't go far enough. I think that the "type id" intrinsic should only work for T:'static

[alexcrichton]

Hm, this could get interesting. So in theory the signature of the type_id intrinsic is fn type_id<T: 'static>() -> u64, but this means that callers need to have a 'static bound, which Any currently does not, and apparently you can't make trait Foo: 'static.

This also seems a little limiting to the Any trait to make it only applicable for types which don't have any borrowed pointers inside of them. It looks like the types that we're hashing aren't necessarily the "trans types" in that they've had all their regions substituted, so why can't we hash the regions as well? You could have some possibly equivalent types have different types, but I think that it's fine to have that happen (especially when lots of weird regions are involved).

[thestinger]

The monomorphize pass isn't going to output new functions when the region parameters are different. It will generate incorrect code if you're giving runtime meaning to regions. If a function calls type_id, it's only going to output one version of it for any set of type parameters, regardless of the regions involved.

[glaebhoerl]

@brson GHC uses [u64, ..2]

[DaGenix]

Due to SipHash having such a small output size, I think collisions are a concern. I believe I found a theoretical collision: https://gist.github.com/DaGenix/7390603. Collisions are fairly unlikely unless you are specifically looking for one, but, if collisions can be found they can also happen by accident. Is this an problem? I didn't want to open up an issue until someone that understands the impacts of such a collision better than I do took a look and I wasn't sure where else to post.

[thestinger]

Yes, it's a problem. If there are collisions and the library assumes there aren't, Rust isn't memory safe.

[DaGenix]

I opened #10389.