Open kaleidawave opened 4 months ago
Quick thoughts:
Considering struct TypeId { block: u16, offset: u16 }
. Where BlockId
points to a collection of Vec<Type>
that can span multiple files / packages. But each block only contains types per module so that invalidations have a limited effect or something.
I think the first thing is to split types apart.
TypeId should be InterfaceTypeId | ConstantId | FunctionId | ...
with each of them having their own Vec
Could try splitting types that an expression can represent from conventional types again at some point. Although makes subtyping less simple
Currently all types are currently held under a single
Vec<Type>
, andTypeId
is pointer into this vector. TypeId is a wrapped for a u16. To support larger files/codebases this needs to increaseCurrently the sequential ids require the whole program to be checked (from a starting point). Adding more incremental parts will create problems if an intermediate file is changed.
TypeId
has to be split between libraries/files somehow.Also from #103: Adding versioning or something to the binary format that can be checked on deserialization. This is because new versions of the compiler might have a different representation in byte form (new fields, removed enum members, etc) that isn't compatible to be parsed with binary files generated by older compilers