This bug is for the syntax/binary encoding changes needed to align with WABT/V8's GC prototyping work. This is for the subset that we currently implement, and isn't about new features.

Depends on D69405

The encoding for ref/optref is left to its own commit as that implies a larger
change to rename the actual TypeCode.

Depends on D69406

Depends on D69407

WABT encodes type then flag in struct fields.

Depends on D69408

Depends on D69409

Depends on D69410

https://hg.mozilla.org/mozilla-central/rev/6925085a3958
https://hg.mozilla.org/mozilla-central/rev/34b14f96f32c
https://hg.mozilla.org/mozilla-central/rev/5ee4bec9fb29
https://hg.mozilla.org/mozilla-central/rev/44e1642ff102
https://hg.mozilla.org/mozilla-central/rev/10af84a356f7
https://hg.mozilla.org/mozilla-central/rev/293fc1055c2e
https://hg.mozilla.org/mozilla-central/rev/9a64ef57fd25

FTR, it appears this broke my build (on macOS), with a Rust compile failure:

 3:07.06    Compiling baldrdash v0.1.0 (/Users/jkew/mozdev/mozilla-unified/js/src/wasm/cranelift)
 3:07.57 error[E0599]: no variant or associated item named `OptRef` found for enum `bindings::low_level::TypeCode` in the current scope
 3:07.57    --> js/src/wasm/cranelift/src/bindings/mod.rs:112:27
 3:07.57     |
 3:07.57 112 |                 TypeCode::OptRef | TypeCode::AnyRef | TypeCode::FuncRef | TypeCode::NullRef => {
 3:07.90     |                           ^^^^^^ variant or associated item not found in `bindings::low_level::TypeCode`

After clobbering, it now seems to be building successfully, so I guess the push here should really have updated the CLOBBER file.

so I guess the push here should really have updated the CLOBBER file.

...or there's some kind of dependency missing from the build system.

(In reply to Jonathan Kew (:jfkthame) from comment #11)

FTR, it appears this broke my build (on macOS), with a Rust compile failure:

 3:07.06    Compiling baldrdash v0.1.0 (/Users/jkew/mozdev/mozilla-unified/js/src/wasm/cranelift)
 3:07.57 error[E0599]: no variant or associated item named `OptRef` found for enum `bindings::low_level::TypeCode` in the current scope
 3:07.57    --> js/src/wasm/cranelift/src/bindings/mod.rs:112:27
 3:07.57     |
 3:07.57 112 |                 TypeCode::OptRef | TypeCode::AnyRef | TypeCode::FuncRef | TypeCode::NullRef => {
 3:07.90     |                           ^^^^^^ variant or associated item not found in `bindings::low_level::TypeCode`

After clobbering, it now seems to be building successfully, so I guess the push here should really have updated the CLOBBER file.

Ah, I'm sorry about that! This seems like a potential issue with our use bindgen.

I changed a TypeCode in 'wasm/WasmConstants.h', which is included by 'baldrapi.h', which is processed by bindgen. It looks like the build.rs which triggers bindgen is set to only run if 'baldrapi.h' is changed. [1]

Benjamin, do we need to add 'WasmConstants.h' as a 'rerun-if-changed' file?

I also see bindgen has a 'builder.parse_callbacks(Box::new(bindgen::CargoCallbacks))' option which seems to automatically print rerun-if-changed for all includes. I don't see it used in any other bindgen projects in tree though, so I don't know if there's a reason for that.

[1] https://searchfox.org/mozilla-central/rev/4ccefc3181f9d237ef4ca8bd17b4e7c101ddf7b5/js/src/wasm/cranelift/build.rs#31

Benjamin, do we need to add 'WasmConstants.h' as a 'rerun-if-changed' file?

Yes, this seems sensible. Sorry I didn't think about such a build failure possibility! (And it's a bit amazing it didn't happen earlier.) We could also try the parse_callbacks thing, if it worked.

parse_callbacks(Box::new(CargoCallbacks)) should just work (tm), and if not I'd be interested in knowing why not :)