The flag --enable-gc of wat2wasm has no effect.

[soegaard]

According to https://github.com/WebAssembly/wabt/issues/2530 the work on the GC proposal is currently not in the main branch.

The help text of wat2wasm lists the flag --enable-gc anyways, since all tools shares the same set of options.

For wat2wasm this flag thus have no effect.

Either the flag should not be listed for wat2wasm in the help text or there should a text explaining that it currently has no effect.

[keithw]

The documentation seems relatively clear about which proposals are supported (https://github.com/WebAssembly/wabt/?tab=readme-ov-file#supported-proposals). GC is not in there.

The --enable-gc flag enables the in-development GC support which is currently partial... but there needs to be some flag for it. We can rename it to something else (like --enable-gc-experimental) if you want.

Or if you just want GC support, users can use wasm-tools which has it. (https://github.com/bytecodealliance/wasm-tools)

[soegaard]

I should have included some more context from the closed PR.

How about just renaming it to --enable-gc-experimental?

I would interpret a flag --enable-gc-experimental as "GC is implemented, but it is still a WIP". Or perhaps that the specification might change. My understanding is that --enable-gc is a noop for wat2wasm.

From the perspective of a user new to Wasm that just wants to try out Wasm: he sees i31 in the GC spec. Checks the help of wat2wasm and sees he must use --enable-gc to use the GC proposal. To his surprise none of the example programs works.

Adding a line in the README would help. Removing the flag from the help text of wat2wasm even better.

I'll close this PR (since the fix was wrong) and create an issue instead.

[sbc100]

enable-gc is doesn't look like a no-op to me. It looks like it at least has some effect on the parser and binary readers:

$ git grep gc_enabled
Binary file docs/demo/libwabt.js matches
src/binary-reader.cc:    if (options_.features.gc_enabled()) {
src/binary-reader.cc:        ERROR_UNLESS(options_.features.gc_enabled(),
src/binary-reader.cc:        ERROR_UNLESS(options_.features.gc_enabled(),
src/emscripten-exports.txt:_wabt_gc_enabled
src/emscripten-exports.txt:_wabt_set_gc_enabled
src/wast-parser.cc:       !options_->features.gc_enabled())) {
src/wast-parser.cc:    if (!options_->features.gc_enabled()) {
src/wast-parser.cc:    if (!options_->features.gc_enabled()) {

[soegaard]

I am strictly speaking of wat2wasm.

[sbc100]

I am strictly speaking of wat2wasm.

wat2wasm uses the wast parser to parse its input.

The set of features that can be enabled are shared between all different tools.

[soegaard]

I think, I got the wrong impression (that the flag was a no-op) reading Issue #2530 . I just happened to use some test programs that used i31.

So renaming to --enable-gc-experimental makes more sense to me now.

I'd like a note in the help message for wat2wasm on what is missing though.

[sbc100]

I think you can update the description in include/wabt/feature.def to have the help message automatically updated.