The `Any` trait should not use virtual calls for type checks

[pcwalton]

These are slow and should be unnecessary. They are showing up in Servo profiles.

[pcwalton]

To be clear what it should be doing instead: It should be pulling the vtable out of the trait object and inspecting the tydesc therein directly.

[nikomatsakis]

This would also address #10389

[nikomatsakis]

Well, it might address #10389 anyway. Though I think in practice we'd probably have to limit the types that Any could be applied to to nominal types which can have a unique type descriptor -- actually, I wasn't considering genericity. Even that doesn't work so obviously well. Never mind. Carry on.

[Kimundi]

Any using the typedesc from the vtable was the initial design, I changed it to what got merged for two reasons:

1. typedescriptors can be duplicated, making type equality not work across crate
2. @thestinger mentioned that having the type descriptor in the vtable at all is something that he'd like to see changed, as it prevents merging of identical vtables, which means using virtual calls is the only way to encode the information in a trait object.

[nikomatsakis]

We can also just add a u64 field to the struct that stores the hash/whatever-code-we-eventually-settle-on. That would prevent virtual calls, we'd just have to load the field and compare.

[eddyb]

There are two non-Any-specific-compiler-magic ways of solving this, that I can think of:

• if we had pure functions, a pure method taking no arguments could be replaced in the vtable by its result (and on x64, we could represent &Any as (TypeId, *data), since the method returning the TypeId would be the only one in the vtable - this is an optimization I've mentioned a few times before)
• associated items in traits could also provide the optimizations mentioned above (might require CTFE if they are treated like today's statics)

[treeman]

Triage bump, carry on.

[eddyb]

Given that we are going to get associated items, an associated constant with get_type_id::<Self>() as the value seems like the best option.
The intrinsic call could be allowed without any form of CTFE.

[thestinger]

There's no type id or type descriptor in the virtual function table right now. There's only a slot for a destructor and then the methods.

[Yoric]

If someone is willing to mentor me on this, I'd be interested in giving it a try.

[eddyb]

@Yoric It's a design problem, i.e. how do you represent the TypeId in Any such that it's a load of a vtable field?

I was going to go with "associated constant" a while back, but now that trait objects work by having the compiler implement Trait for Trait, with each method that is available (i.e. not those with where Self: Sized) forwarding through the vtable, there is a problem:

Anything that has to look up the vtable needs access to self, and this rules static methods and associated constants.
I would be happy with a compromise, such as trait_object.CONST which doesn't go through the Trait impl for Trait shim, but I doubt others would like that.