Fix const enum compilation failure

[DuncanUszkay1]

Issue: #574

If you tried to use a const enum with multiple members, you would receive a compilation failure.

This was because the compiler relied upon each enum value to be registered as a global value in order to determine what the next enum value was. As a result, when we inlined the enum values and did not register that global value, compilation would fail.

To fix this, I've changed this method around a bit to rely upon the last expression value used (held in initExpr) rather than trying to load from the global store.

I'm not sure why it was implemented the way it was originally- it's possible that there is some tradeoff involved here I'm unaware of which causes reading from the global store to be faster/more efficient than simply reusing the last expression statement used in the loop. This certainly seems to work from a functional perspective 🤷‍♂

[dcodeIO]

I believe the underlying idea was that if one has an enum like

enum A {
  A
}

that the value of A would be 0 since it's the first value (no initializer, no previousValue) and if one has an enum like

enum A {
  B = 2;
  C;
}

that the value of C would become B + 1.

Regarding the PR specifically, it is not possible to reuse the same expression as a member of two different expressions, so if B is initialized with initExpr, that same initExpr cannot be used again to initialize C, but one must global.get the value of A.B (use a new expression).

Looks like there should instead be a case where if the enum is const, it would make a new expression of the inlined value, and if it is mutable, use a global.get as it did.

[DuncanUszkay1]

You say it isn't possible, but the code seems to work 🤔 here's the example that wasn't previously working:

// foo.ts
export const enum Foo {
  Boo1, Boo2, Boo3, Boo4
}

// main.ts
import { Foo } from './foo';

export function test(): i32 {
  return Foo.Boo1 + Foo.Boo2 + Foo.Boo3 + Foo.Boo4);
}

With this change it compiles and outputs: 6. Seems like tests pass as well

What's the scenario where this fails? Not sure I understand

[dcodeIO]

Not reusing the same expression multiple times is a Binaryen convention. From their README:

Notes when working with Binaryen IR:

As mentioned above, Binaryen IR has a tree structure. As a result, each expression should have exactly one parent - you should not "reuse" a node by having it appear more than once in the tree. The motivation for this limitation is that when we optimize we modify nodes, so if they appear more than once in the tree, a change in one place can appear in another incorrectly.

[DuncanUszkay1]

Ah I see. Back to the drawing board, I'll look into what you suggested above. Thanks for the review

[DuncanUszkay1]

This should be ready for review again

[dcodeIO]

Thank you! :)