-
-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(codegen): type safe inkwell types #202
refactor(codegen): type safe inkwell types #202
Conversation
Codecov Report
@@ Coverage Diff @@
## master #202 +/- ##
==========================================
- Coverage 82.95% 82.08% -0.87%
==========================================
Files 163 174 +11
Lines 11514 11665 +151
==========================================
+ Hits 9551 9575 +24
- Misses 1963 2090 +127
Continue to review full report at Codecov.
|
61c12b2
to
f6d8cb3
Compare
9352194
to
a4ed234
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Props for this change. 👏 I had some minor requests for change.
0b64c3b
to
305b008
Compare
Inkwell uses types that lose a lot of type information. An
u8
,u16
,i8
, and16
are all represented by anIntValue
. This takes some careful management of these types. ForIntValue
the problem is not so bad but forPointerValue
andStructValue
this is a real issue. By usingStructValue
you lose all information in the type with what kind of value you are actually working. This is not so much a problem for dynamic types (like Mun structs) but it is a major risk when using abi types. I feel that this is major technical depth.This PR introduces a new type
Value<T>
that contains an inkwell value but it is typed onT
which is the type that constructed the value. This allows you to write:It also allows much cleaner conversion from regular Rust types to inkwell types. e.g.
There are 3 ways to enable custom types to work with this system:
Implement the
TransparentValue
trait which converts the implementor into anotherValue<T>
. But in turn it also allows the implementor to be represented as aValue<Self>
:The resulting IR type will be an anonymous type:
type { u32, f32 }
Auto derive the
AsValue
trait e.g.:The resulting IR type will be a named type:
%Foo = type { u32, f32 }
You can also implement all the support traits yourself for a custom type.
I already found a few bugs in the LLVM ir that have been fixed.
TODO
abi_types.rs
to use the types fromValue<T>
sValue<T>
typesir::TypeInfo
should equalabi::TypeInfo
)ir.rs
) (do in a later PR)