SafeMemberExpression transform is mangling AST inside fat arrows

[plexigras]

in

-> x.y?.z //works
=> x.y?.z //doesnt

out

(function() {
  var _ref;

  return (_ref = x.y) == null ? null : _ref.z;
}); //works
() => {
  var _ref2;

  return _ref2.z;
}; //doesnt

[wcjohnson]

Reopening.

[wcjohnson]

From these facts:

• Only happens with fat arrows
• Does not happen with fat arrows when they have a multi-statement body or a braceblock.

This isolates the problem to ArrowFunctionExpressions with expression bodies. I believe I have located and fixed this problem, which is incredibly obscure. What's happening is that when the compiler hoists the ref here:

https://github.com/wcjohnson/babel-plugin-lightscript/blob/e99764bac97c993a4b7b205c95b105ea1cc509f0/src/safe.lsc#L55

It is mutating the AST by adding a function body, but then path becomes an invalid pointer to a piece of AST that no longer exists.

The solution is to ensure the function has a block body before running the hoist, and re-grabbing a valid path before all the mangling happens.

I am implementing and testing a "lazy man" fix now, which will directly address this specific problem. However, our general approach to safe traversal is not correct. @rattrayalex mentioned https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-optional-chaining/src/index.js which looks like a much better algorithm for handling this.

Longer term plan here is to adopt the Babel approach altogether, which means:

• Using the Babel algorithm from transform-optional-chaining
• Adopting the Babel ast conventions as well: no more SafeMemberExpression, instead MemberExpression with optional = true property. Same thing with Safe Calls, which will be implemented as CallExpression with optional = true.
• Adopt JS proposed standard parsing for safe calls a?.(b)
• I will probably continue to allow the shorter safecall syntax a?(b) in addition to the proposed JS syntax, since I have resolved the parsing ambiguities there to my own satisfaction.

[wcjohnson]

Leaving this open to track future convergence toward the Babel algorithm. See also lightscript#46

[wcjohnson]

Fixed in 3.0 branch: wcjohnson/babel-plugin-lightscript@760ec66