[Parser] Parse ref.func #6097
[Parser] Parse ref.func #6097
Conversation
|
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
| @@ -839,7 +839,10 @@ Result<> IRBuilder::makeRefIsNull() { | |||
| return Ok{}; | |||
| } | |||
|
|
|||
| // Result<> IRBuilder::makeRefFunc() {} | |||
| Result<> IRBuilder::makeRefFunc(Name func) { | |||
| push(builder.makeRefFunc(func, wasm.getFunction(func)->type)); | |||
There was a problem hiding this comment.
Consider adding a comment about wasm-ir-builder having a stricter makeRefFunc() than wasm-builder, one that will throw an exception if the function being made reference to is not already added to the module.
There was a problem hiding this comment.
I'll add a general comment about this to the top-level IRBuilder doc comment because this applies to many functions.
| (func $ref-func | ||
| ref.func $ref-func | ||
| drop | ||
| ref.func 102 |
There was a problem hiding this comment.
How did you know $ref-func was at function index 102?
| @@ -388,9 +388,8 @@ struct NullInstrParserCtx { | |||
| return Ok{}; | |||
| } | |||
| Result<> makeRefIsNull(Index) { return Ok{}; } | |||
|
|
|||
| Result<> makeRefFunc(Index, FuncIdxT) { return Ok{}; } | |||
There was a problem hiding this comment.
What's the NullInstrParserCtx for?
There was a problem hiding this comment.
The first few phases of parsing only care about finding top-level module elements like globals, functions, etc, or parsing types, so they don't need to do anything interesting with the instructions. The parser contexts for those phases inherit from NullInstrParserCtx to avoid having to repeat this "do nothing" behavior for each of them separately.
tlively
force-pushed
the
parser-ref-func
branch
from
1cdd37b
to
7f818b5
Compare
No description provided.