-
Notifications
You must be signed in to change notification settings - Fork 16
Function References Draft #168
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.