Support table initializer expressions; completes function references support #2593

zherczeg · 2025-04-29T13:27:06Z

Another large patch on the top of the other two. Now there are 3-4000 lines of new code is waiting for review, and it looks like the end is still far.

The painful part so far:
https://webassembly.github.io/function-references/core/binary/modules.html#element-section

Since type 0-3 is reserved for (ref func), all (elem ... funcref ...) must be encoded with 4-7, which increase binary size. This affect several tests, and probably real word programs :(

There are spec tests to check this behavior.

zherczeg · 2025-05-01T07:30:36Z

Function references is a Phase 5 (The Feature is Standardized) proposal for WebAssembly. It is a requirement for the Garbage Collection proposal. It is part of the WebAssembly 3.0 draft as well:

https://webassembly.github.io/spec/versions/core/WebAssembly-3.0-draft.pdf

The overview of the proposal isn't that long, but it turned out that it affects all parts of the project, since types are everywhere and type comparisons / validations are frequently used. Nullable / non-nullable references (e.g. tables with initializers and/or active elem initializers, etc.) requires many extra checks as well. Imports are on another level, since you need to validate them across modules. I have no idea how a native function can define references though, there is no module assigned for them.

This amount of work this feature needs was unexpected for me. Unfortunately, this is unavoidable. I made many patches, and these cover most specification tests, although some of them are still just partly supported. However, I don't get any reviews for them. I would like to understand why.

Is this a feature which does not align with the aims of wabt?
Are these changes too big / too risky?
Any other reasons?

It is very hard to make progress when I don't get any feedback, and I need to maintain several patches. Is there a chance these patches will land?

sbc100 · 2025-05-06T06:01:53Z

This amount of work this feature needs was unexpected for me. Unfortunately, this is unavoidable. I made many patches, and these cover most specification tests, although some of them are still just partly supported. However, I don't get any reviews for them. I would like to understand why.

Is this a feature which does not align with the aims of wabt?

Are these changes too big / too risky?

Any other reasons?

It is very hard to make progress when I don't get any feedback, and I need to maintain several patches. Is there a chance these patches will land?

Sorry for the lack of feedback on some of your patches. Unfortunately there are very few folks to who have any time to work on wabt these days (or review patches).

Please expect fairly long feedback cycles. If you are waiting for a review from me, feel free to ping me a every couple of days, but please understand that I have very few cycles to spend on wabt myself.

For some background on where some folks see wabt heading see this issue: #2348. If you would like to help maintain wabt going forward, and potentially work on major additions such as GC please join that discussion.

zherczeg · 2025-05-06T13:32:24Z

Thank you for the suggestion!

zherczeg · 2025-05-08T12:45:39Z

The patch set (#2562, #2567, and this patch) covers 25 tests from the 26 spec tests in testsuite/proposals/function-references. That is 96% pass rate. The missing one is ref.wast, which needs removing the invalid reference test during parsing.

sbc100 · 2025-05-08T15:31:35Z

The patch set (#2562, #2567, and this patch) covers 25 tests from the 26 spec tests in testsuite/proposals/function-references. That is 96% pass rate. The missing one is ref.wast, which needs removing the invalid reference test during parsing.

Nice! Thanks for all the hard work on this.

I assume #2562 is the first in the series and the one we should look at first?

BTW can you have this PR a better title? Support table initializers sounds odd because that is obviously something that wabt already supports. Perhaps you mean a certain type of new table intializer?

zherczeg · 2025-05-08T17:45:20Z

I assume #2562 is the first in the series and the one we should look at first?

Yes. It focuses on extending the existing features, e.g. tables / globals now supports refs. Recursive refs, and not initalized non nullable refs are detected as well.
The next patch focuses on adding new byte codes.
The last focuses on a new initializer value for tables. It breaks the current API.

BTW can you have this PR a better title? Support table initializers sounds odd because that is obviously something that wabt already supports. Perhaps you mean a certain type of new table intializer?

I am open to any ideas.

https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md#tables
Tables can have an optional initializer value, and all elements of the table is set to that value when the table is constructed (before active elems are processed). If ref.null is not possible for a table (e.g. it has (ref func) type), the initializer is mandatory.

Btw I found a case, which has no spec test, and the specification is unclear:

(table (ref func) (elem 1)) -> since all elements of the table is initialized, it seems the initializer is unnecessary.

However, if I do the inlining here, I should get a missing initializer error:
https://webassembly.github.io/function-references/core/text/modules.html#tables
And I have no idea how the binary should be constructed. Maybe the first function could be the initializer.

keithw · 2025-05-08T17:57:52Z

FWIW, when I hit a case where the prose spec is unclear, I usually just go try it in the reference interpreter and in wasm-tools. If those two disagree, it's an even better opportunity to submit a new test case. :-) Andreas is usually very quick about accepting new test cases into the spec repo.

zherczeg · 2025-05-09T11:14:26Z

The last test is done, now all spec test are pass.

zherczeg

@sbc100 this is the last patch of the function references proposal.

zherczeg · 2025-11-09T07:27:55Z

include/wabt/binary-reader-logging.h

+                    bool has_init_expr) override;
+  Result BeginTableInitExpr(Index index) override;
+  Result EndTableInitExpr(Index index) override;
+  Result EndTable(Index index) override;


Since tables can have an initializer expressions now, this is a breaking change. I don't know how these are handled in this project.

zherczeg · 2025-11-09T07:37:53Z

README.md

 | [extended-const][]    | `--enable-extended-const`   |   | ✓ | ✓ | ✓ | ✓ | ✓ |
 | [relaxed-simd][]      | `--enable-relaxed-simd`     |   | ✓ | ✓ | ✓ | ✓ |   |
 | [custom-page-sizes][] | `--enable-custom-page-sizes`|   | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [function-references][] | `--enable-function-references` |   | ✓ | ✓ | ✓ | ✓ |   |


I haven't used update-spec-tests.py and updated README before, so these are just speculative changes.

zherczeg · 2025-11-09T07:50:14Z

test/dump/typed_func_refs_params.txt

  )

-  (elem declare funcref (ref.func $square))
+  (elem declare func $square)


There are similar changes below. The reason is a backward incompatible change. As for elem types 0-3, they have changed the result type from (ref null func) (same as funcref) to (ref func). This change affects table type matches.

sbc100

Great! Thanks for all the work on this!

Can you update the PR description to match what you would like in the final commit?

sbc100 · 2025-11-13T18:30:36Z

include/wabt/ir.h

 struct ElemSegment {
  explicit ElemSegment(std::string_view name) : name(name) {}
-  uint8_t GetFlags(const Module*) const;
+  uint8_t GetFlags(const Module*, bool) const;


Can you give this new argument a name?

Yes. Since a bool (options_.features.function_references_enabled()) is passed, I would not introduce an enum for this.

sbc100 · 2025-11-13T18:31:27Z

include/wabt/shared-validator.h


  Result OnFunction(const Location&, Var sig_var);
-  Result OnTable(const Location&, Type elem_type, const Limits&);
+  Result OnTable(const Location&, Type elem_type, const Limits&, bool, bool);


Can you name these new arguments? (seems especially important for bool)

sbc100 · 2025-11-13T18:32:48Z

src/binary-reader-objdump.cc

+  Result BeginTable(Index index,
+                    Type elem_type,
+                    const Limits* elem_limits,
+                    bool) override;


Name here too please

sbc100 · 2025-11-13T18:34:54Z

src/binary-reader.cc

+    bool has_init_expr = false;
+
+    if (options_.features.function_references_enabled() &&
+        state_.offset < read_end_ && state_.data[state_.offset] == 0x40) {


What is this 0x40 value? Maybe at least deserves a comment, if not a name.

It looks like you are peeking at the next byte here.. is there perhaps a helper function for that?

I have added the comment. I could not find a helper for peaking a byte, probably this is something new as well. I will add something then.

I chose a different direction at the end. It does not need peak, but some code duplication is needed. However, it is clearer, that the 0x40 is the leb32 representation of Type::Void.

src/binary-reader.cc

sbc100 · 2025-11-13T18:45:16Z

src/ir.cc


-uint8_t ElemSegment::GetFlags(const Module* module) const {
+uint8_t ElemSegment::GetFlags(const Module* module,
+                              bool function_references_enabled) const {


It seems a little odd that that we don't have any other features in ir.cc, I guess we have gotten away to a feature-agnostic IR up until this point.

Normally, new features are backward compatible, so you don't need flags for them (the parser will check the feature). This is probably the first exception.

sbc100 · 2025-11-13T18:47:23Z

src/shared-validator.cc

-      !options_.features.reference_types_enabled()) {
+  if (options_.features.reference_types_enabled()) {
+    if (!elem_type.IsRef()) {
+      result |= PrintError(loc, "tables must have reference types");


How about "tables may only contain reference types"? i'm not sure its any better actually :)

sbc100 · 2025-11-13T18:49:57Z

src/validator.cc


+  if (actual_type == Type::FuncRef && expected_type == Type::RefNull) {
+    // Specification tests pass expected functions
+    // directly, their type is not relevant.


I'm not sure I understand this comment here, does it need updating?

I have updated the description. There is a test: (assert_return (invoke "ref") (ref.null)), where the value is null without any actual type. Unfortunately we only get the types, not the values, so this check is not perfect, but I have no idea how to do this differently.

sbc100 · 2025-11-13T18:51:04Z

src/validator.cc

-          result_ |=
-              validator_.OnTable(field.loc, table.elem_type, table.elem_limits);
+          result_ |= validator_.OnTable(field.loc, table.elem_type,
+                                        table.elem_limits, true, false);


Might be nice to have Enums to avoid all these true / false arguments, but not a huge deal, and I think we have a lot of them already probably.

sbc100 · 2025-11-13T18:52:45Z

src/wast-parser.cc


  if (type->GetReferenceIndex() != kInvalidIndex) {
-    // Resolved earlier.
+    // Index or resolved earlier.


Comment doesn't seem to maker sense. Is there a typo?

sbc100 · 2025-11-13T18:57:47Z

What do you think about re-titling: "Support table initializer expressions; completes function references support"

…support

zherczeg · 2025-11-14T11:17:41Z

Thank you for the review. I changed the title, and I hope I fixed every request. Please check the patch again.

zherczeg force-pushed the table_init branch from 082b107 to 82a927f Compare April 29, 2025 15:10

zherczeg force-pushed the table_init branch from 82a927f to aa7da78 Compare May 6, 2025 05:39

zherczeg force-pushed the table_init branch 2 times, most recently from 6492586 to e92be0b Compare May 8, 2025 12:14

zherczeg marked this pull request as ready for review May 8, 2025 12:19

zherczeg force-pushed the table_init branch 2 times, most recently from ec270d6 to e6dff8a Compare May 9, 2025 09:46

zherczeg force-pushed the table_init branch 2 times, most recently from 22728a7 to a4d9b47 Compare May 21, 2025 07:57

zherczeg force-pushed the table_init branch from a4d9b47 to 5ee89f2 Compare May 22, 2025 05:57

zherczeg force-pushed the table_init branch from 5ee89f2 to b0bbd04 Compare June 3, 2025 10:44

zherczeg force-pushed the table_init branch 3 times, most recently from dda079f to bec3c3b Compare June 22, 2025 18:26

zherczeg force-pushed the table_init branch 3 times, most recently from 30e7b37 to a7701de Compare June 26, 2025 14:36

zherczeg mentioned this pull request Nov 8, 2025

Add support for (ref ...) / (ref null ...) constructs #2562

Merged

zherczeg force-pushed the table_init branch from a7701de to a447b9c Compare November 9, 2025 07:25

zherczeg commented Nov 9, 2025

View reviewed changes

sbc100 approved these changes Nov 13, 2025

View reviewed changes

zherczeg changed the title ~~Support table initializers~~ Support table initializer expressions; completes function references support Nov 14, 2025

zherczeg force-pushed the table_init branch 3 times, most recently from 22c1d56 to 518626e Compare November 14, 2025 10:36

Support table initializer expressions; completes function references …

64d8892

…support

zherczeg force-pushed the table_init branch from 518626e to 64d8892 Compare November 14, 2025 11:04

sbc100 merged commit 8be9a01 into WebAssembly:main Nov 14, 2025
17 checks passed

zherczeg deleted the table_init branch November 14, 2025 16:42

Support table initializer expressions; completes function references support #2593

Support table initializer expressions; completes function references support #2593

Uh oh!

Conversation

zherczeg commented Apr 29, 2025

Uh oh!

zherczeg commented May 1, 2025

Uh oh!

sbc100 commented May 6, 2025

Uh oh!

zherczeg commented May 6, 2025

Uh oh!

zherczeg commented May 8, 2025

Uh oh!

sbc100 commented May 8, 2025

Uh oh!

zherczeg commented May 8, 2025

Uh oh!

keithw commented May 8, 2025

Uh oh!

zherczeg commented May 9, 2025

Uh oh!

zherczeg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zherczeg commented Nov 14, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sbc100 commented Nov 13, 2025 •

edited

Loading