You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
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?The text was updated successfully, but these errors were encountered: