-
Notifications
You must be signed in to change notification settings - Fork 16
Description
Generics are weird in that ideally they don't matter for ABI (at least in Rust/C++), thanks to monomorphization. So supporting generics would be a lot of work, for unclear benefit... but y'know extend that logic far enough and you reason away abi-cafe.
The only case fresh on my mind that relates to generics and ABIs causing problems is actually just a bug in generic functions resulting in varargs being invoked incorrectly (because analysis is done premonomorphization, oops!).
Catching that case would involve a lot more than this issue is proposing.
So right now we of course have a sort of generics with structural types, but the key "trick" here is that we essentially monomorphize all structural types before assigning them type ids (TyIdx). That is, &u32
and &i32
each get a different TyIdx and Ty. As a result, everything can key off of TyIdx for looking up facts about a type, computing type definition dependencies, and interning type names or whatnot.
Once you introduce the concept of a single struct "MyType<T>" { .. }
definition which "MyType<i32>"
, "MyType<bool>"
, and "MyType<T>"
all reference, you need to introduce some kind of "substitutions" system for talking about the types and the types of their fields.
One option would be to still fully monomorphize these types into their own TyIdx and Tys -- essentially generating MyType_u32
and so on -- but with some additional layer of abstraction for looking up a "type definition id". This would leave the complexity largely the same for codegen backends? I think?
Activity