Regarding computed field writes

[meetesh06]

I was looking at the generated bytecode for computed field writes and cant understand the need for the is_undefined_or_null check.

a["x"] = 12;

  //       push_this          [this]
  //       if_false8       4  []
  //       return_undef       []
  //   4:  get_var         a  [a]
  //       push_atom_value x  [a, "x"]
  //       swap               ["x", a]
  //       dup                ["x", a, a]
  //       is_undefined_or_null ["x", a, bool]
  //       if_true8        22   ["x", a]
  //       swap                 [a, "x"]
  //       to_propkey           [a, toPropKey("x")]
  //       swap                 [toPropKey("x"), a]
  //  22:  swap                 [a, toPropKey("x")], [a, "x"]
  //       push_i8         12   [a, toPropKey("x"), 12], [a, "x", 12]
  //       swap                 [a, 12, toPropKey("x")], [a, 12, "x"]
  //       to_propkey           [a, 12, toPropKey(toPropKey("x"))], [a, 12, toPropKey("x")]
  //       swap                 [a, toPropKey(toPropKey("x")), 12], [a, toPropKey("x"), 12]
  //       put_array_el         [], []
  //       undefined            [undefined]
  //       return_async         []

Why do we need to do toPropKey twice if the receiver object is ~(null or undefined)? or does this handle some other case?

[bnoordhuis]

No particular reason, it's just a missed optimization opportunity. quickjs only does ultra-local bytecode optimizations.