[JS API] support heap type none

[chharvey]

BinaryenTypeNone refers to the type
with stack effect [] -> [] (e.g. the (nop) instruction).

BinaryenHeapTypeNone is the new GC heap type none, which is
“the common subtype of all forms of aggregate types.”
(https://webassembly.github.io/spec/core/syntax/types.html#heap-types)

The former had been named 'none' in the JS API, predating the GC proposal.
However, this can be confusing with GC heap type support now finalized in Binaryen.
This PR renames the old type 'none' to 'void',
and adds support for the heap type and gives it the name 'none'.

This is a breaking change. Users who write binaryen.none,
when referring to the empty type, must rename it to binaryen.void.
The type binaryen.none may still be used but now refers to the GC heap type.

[kripken]

The breaking change also has the effect of calling the C++ Type::none by the name void in JS, which seems confusing. It would be better to keep them parallel.

Is the problem that we have both a Type and a HeapType called "none", but JS puts them all in the same namespace? Then I wonder if we can use a separate namespace for Types and HeapTypes.

[chharvey]

@kripken I do like that idea, because with all the different types and heap types at the same binaryen.* global namespace it gets very cluttered.

Would they be better organized into enums? We could build off the names binaryen.Type, binaryen.HeapType, and binaryen.PackedType, which are already used in AssemblyScript’s type definitions and in the proposed TS migration.

Something like:

  Module['Type'] = {};
  [
    ['none', 'None'],
    ['i32', 'Int32'],
    ...
  ].forEach(entry => {
    Module['Type'][entry[0]] = Module['_BinaryenType' + entry[1]]();
  });
  Module['HeapType'] = {};
  [
    ['none', 'None'],
    ['func', 'Func'],
    ['extern', 'Ext'],
    ...
  ].forEach(entry => {
    Module['HeapType'][entry[0]] = Module['_BinaryenHeapType' + entry[1]]();
  });
  Module['PackedType'] = {};
  [
    ['notPacked', 'NotPacked'],
    ['i8', 'Int8'],
    ['i16', 'Int16']
  ].forEach(entry => {
    Module['PackedType'][entry[0]] = Module['_BinaryenPackedType' + entry[1]]();
  });

and then in the TypeScript typings:

// all exported under the `binaryen.*` namespace
export type Type = number;
export type HeapType = number;
export type PackedType = number;

export const Type: {
  none: number,
  i32: number,
  ...
};
export const HeapType: {
  none: number,
  func: number,
  extern: number,
  ...
};
export const PackedType: {
  notPacked: number,
  i8: number,
  i16: number,
};

As far as I know, TypeScript lets you export both a type and a const (a value) with the same name without conflict. Would want to test it to be sure though.

Of course this would still a breaking change as users would need to update all references to types, but probably for the better.

Or we could go in a different direction, so would want to hear from the other JS devs before committing to a decision.

[kripken]

Yes, some kind of enums make sense to me too. This does require a breaking change as you say, but it seems worth it to me.

cc @brendandahl for TypeScript and general design thoughts here

[chharvey]

closing in favor of #9098