Sub-Types (Type Safety v1.1) about inkwell HOT 7 OPEN

num crate doesn't look like it could help but typenum defines types for a lot of int sizes. So we could probably use those for custom width types: IntValue<U9>, IntType<I30> along with the builtins: IntType<u32>, etc. Also, I don't think LLVM supports custom width floats (at least not in 3.7) so those would only use builtins, though there's no f16 or f128 yet.

from inkwell.

Also, it seems like signed types should be explicit, though LLVM doesn't make this distinction.

from inkwell.

It's worth noting StructTypes (and probably StructValues) have two interesting properties:

• Can be opaque, that is, no body yet set, which is useful for recursive types. So we need something like StructType<Opaque>. This should allow us to implement a set_body for only for StructType<Opaque>
• StructTypes need a variable number of types. Not sure what kind of support rust has for variable sized tuples, but knowing variable sized arrays, I don't expect it to be great. Need to be able to express something like StructType<(A, B, C, D, ..., Z)>

from inkwell.

After looking at #32, it seems that build_global_string and related build_global_string_ptr methods segfault when called without an active function being built on for some reason (even though the string is global 👀). One possible solution would be to have a subtype for a builder in the context of a function, ie Builder<Global> & Builder<Function> similarly to how librustc_trans has two methods for creating builders (global and function scoped): https://github.com/rust-lang/rust/blob/master/src/librustc_trans/builder.rs#L54-L77

Those two methods could be implemented for only the latter Builder Function subtype.

from inkwell.

I know gtk-rs encountered a similar problem when emulating inheritance in Rust. They came up with an IsA trait which lets you use a child class as its parent.

So you might write a function that takes anything which IsA<IntType>, allowing you to accept a u32, i64, etc.

from inkwell.

Inkwell use to have something like that, however the issue was primarily that the trait would require you to assume the global context which may not always be desired and wasn't super intuitive (why does u64 suddenly have the global context even though my other types have been working with my non global context?)

from inkwell.

We're going to want Builder subtypes, as an unpositioned builder can cause segfaults in many scenarios.

from inkwell.