Weird behavior with constructor parameter properties

[surma]

This was a weird one to track down. Here’s a reduced reproduction.

class X {
  public normal: i32;
  public viaThis: i32;
  constructor(private x: i32) {
    this.viaThis = this.x;
    this.normal = x;
  }
}

const x = new X(4);
export function normal(): u32 {
  return x.normal;
}
export function viaThis(): u32 {
  return x.viaThis;
}

console.assert(instance.exports.normal() === 4);
// This will throw. With asc 0.9.4 it will return `0`
console.assert(instance.exports.viaThis() === 4); 

Fun fact: If you swap the assignments in the constructor, both return 4 🤷

[MaxGraey]

Can confirm

[dcodeIO]

Issue seems to be that when we compile

this.viaThis = this.x

we first compile this.x, which allocates this, and only then wrap it with something that needed the allocation to be performed earlier.

[dcodeIO]

This is taking a little longer since I figured that there are even more problems than that, like this allocations leaking in mixed return from ctor scenarios. So far it looks like the current lazy allocation mechanism causes more problems than it solves, so investigating alternatives.

[dcodeIO]

Quick update: So I thought I had a solution for this, but turned out the codegen is so hacky that it doesn't play well with the ARC finalization passes we have in Binaryen right now. Quite the conflict party between ARC, inlining, autoreleases and whatnot due to automatic allocation semantics of ctors in conjunction with the need to also allow returning explicitly within.

[dcodeIO]

Binaryen PR that should help: WebAssembly/binaryen#2833