-
Notifications
You must be signed in to change notification settings - Fork 10
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
Function References Draft #168
base: main
Are you sure you want to change the base?
Conversation
Thanks @iainsmith!
I would suggest following the structure used in the spec like: /// Reference types
public struct ReferenceType: Equatable, Hashable {
public var isNullable: Bool
public var heapType: HeapType
public static var funcRef: ReferenceType {
ReferenceType(isNullable: true, heapType: .func)
}
public static var externRef: ReferenceType {
ReferenceType(isNullable: true, heapType: .func)
}
public init(isNullable: Bool, heapType: HeapType) {
self.isNullable = isNullable
self.heapType = heapType
}
}
public enum HeapType: Equatable, Hashable {
/// A reference to any kind of function.
case `func`
/// An external host data.
case extern
} |
65c9324
to
9141418
Compare
I added tail-call support in the main branch because function-ref proposal depends on the proposal.
It might also be a good example to see how to implement a new proposal in WasmKit. |
Setup test suite in preparation for adding support for these proposals.
9141418
to
494e878
Compare
We need to change the core `ValueType` modeling to support the concrete heap type, which can reference another type by index, but it would be a non-trivial change. So, for now, we skip parsing the concrete heap type and only support the abstract heap type for now.
Tests/WATTests/EncoderTests.swift
Outdated
// TODO: Enable smoke check for encoding | ||
// _ = try wat.encode() |
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.
I would like to merge this branch once the WAT/WasmParser implementation passes the Spectest suite. I don't have enough time to work on it this week, so I won't push any further commits, but feel free to ask any questions you may have.
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.
Thanks @kateinoigakukun, will look at the commits you pushed and try to focus on the Wat/WasmParser.
Function References Overview Link
👋 I started looking at adding support for the function-references extension. This is very much a work in progress, that I'd appreciate feedback on. I'm still building up context on the codebase, so I suspect I'm missing several fairly obvious issues. If you do check it out locally, feel free to push improvements directly to my branch, and I'll pull them in.
So far:
(ref null? $variable)
syntaxSpectestResult
top level so that we can track partially implemented proposals.call_ref
(that's not passing the call_ref.wast tests yet)TODO:
Questions:
I punted on separating out a
HeapType
struct/enum for now, as I wasn't sure what shape it would land up in, and how big the knock on change would be. Do you have a shape in mind for aHeapType
or shall I keep going with the extra cases for ReferenceType for now?I'm hoping to have more time to work on this, but it will depend on other commitments.
I've got 8/34 of the initial
call_ref.wast
tests passing, while the rest are failing withExpected i32 on the stack top but got ref(WasmTypes.ReferenceType.funcRef)
. RuntestFunctionReferencesProposals
if you want to reproduce it locally.