Add support for 'new.target' meta-property

[rbuckton]

This adds support for the new.target meta-property introduced in ES6. This also adds best-effort down-level emit for ES5/3.

NewTarget meta-property

The new.target meta-property is new syntax introduced in ES6. When you create an instance of a constructor via new, the value of new.target is set to be a reference to the constructor function initially used to allocate the instance. If a function is called rather than constructed via new, new.target is set to undefined. In addition, new.target is lexically scoped to the body of the function. As such, it can be captured inside an arrow function.

While it is legal to use new.target in methods and accessors in ES6, those members cannot be called via new as they are not constructors. As such, we have chosen to make it an error to reference new.target in the body of a method or accessor.

ES5 emit

new.target is a pure ES6 syntactic construct that can only be emitted down-level on a best-effort basis. While our emit for new.target is sufficient for ES5 code that interacts with other ES5 code, it does not fully emulate new.target in an ES6 host environment. What this means is that our new.target emit is not compatible with Reflect.construct as we have no way to intercept this API. This emit also is intolerant of explicit changes to the constructor property of the constructor's prototype.

That said, the reason we are introducing best-effort down-level emit for new.target are for several specific use cases pairing ES5 emit for classes with Object.setPrototypeOf or __proto__. One such use case is inheriting from Error in NodeJS v4 and higher:

// ts
class CustomError extends Error {
  constructor(message?: string) {
    super(message); // 'Error' breaks prototype chain here
    (<any>this).__proto__ = new.target.prototype; // restore prototype chain
  }
}

// js
var CustomError = (function (_super) {
  __extends(CustomError, _super);
  function CustomError() {
    var _newTarget = this.constructor;
    var _this = _super.apply(this, arguments);  // 'Error' breaks prototype chain here
    _this.__proto__ = _newTarget.prototype; // restore prototype chain
    return _this;
  }
  return CustomError;
})(Error);

Also, while we can use this.constructor to emulate new.target for classes, we must be more defensive for new.target in a function declaration or function expression. The reason for this is that calling an imported function in a CommonJS, AMD, or System module results in the this argument of the function being bound to the module object (i.e. func() becomes package_1.func()). Also, function expressions are often assigned to a property of an object which could in turn become the this if the function is called as a member.

To defend against this case, the down-level emit for new.target in functions is the following:

// ts
function f() {
  if (new.target) { /* called via 'new' */ }
}

// js
function f() {
  var _newTarget = this && this instanceof f ? this.constructor : void 0;
  if (_newTarget) { /* called via 'new' */ }
}

Fixes #2551

Related:

• https://tc39.github.io/ecma262/#prod-NewTarget - Specification for NewTarget
• Documented breaking change for subclassing built-ins. TypeScript-wiki#100 - Documented breaking change for subclassing built-ins
• Wrong constructor of Error subclass from 2.1.1 #12660 - Wrong constructor of Error subclass from 2.1.1
• Bug or breaking change in super constructors? #12669 - Bug or breaking change in super constructors?

[DanielRosenwasser]

Looks like this can be removed.

[DanielRosenwasser]

Where is this used?

[DanielRosenwasser]

Why is it important that this be distinct from NewTarget?

[rbuckton]

When we compute flags for a member, such as a method or accessor, it both has its own lexical scope (for the parameters and body) as well as shares the lexical scope of its container (due to the computed property name). Without this flag, encountering a NewTarget in a computed property name would incorrectly indicate that NewTarget was set in the body of the method, not in the container.

[DanielRosenwasser]

I'll have to dive in, but can you explain the es2015 transform changes you needed to make?

[rbuckton]

Regarding the changes to the transformer, I am trying to clean up the es2015 transformer and remove some of the variables we use to track state as we descend the tree, this should reduce the overall memory footprint due to values saved on the stack.

Ideally I can use this same mechanism to eventually remove some TransformFlags values (such as LexicalThis capturing) and instead explicitly track the value as we walk back up the spine.

I can isolate these changes to a separate PR if it would be more clear.

[DanielRosenwasser]

newTarget could be undefined if you're somehow not handling a case - consider adding a

Debug.assert(!!newTarget, "'newTarget' should be defined for " + (ts.SyntaxKind as any)[node.kind])

or something similar.

[DanielRosenwasser]

"is then" -> ", then"

[DanielRosenwasser]

You only use this function once - do we anticipate using it again?

[rbuckton]

Yes, I also am using this in the asyncGenerators branch

[DanielRosenwasser]

Do we want to just make this a switch? I think it's asking for it at this point.

[DanielRosenwasser]

I get the crux of the changes which look alright to me - I'm not an expert at the loop conversion code, so @vladima may be a good person to check in with.