Add transpilation support for properties and computed properties from super

[ChadKillingsworth]

This adds support for property references off of super which has been missing from our transpilation support.

[brad4d]

Please add code examples to make it clearer what each of these cases represent.

e.g.
if (exprRoot.getParent().isNew()) {
// new super()

[brad4d]

Why add COMPUTED_PROP? Are you trying to support something like this?

class Foo extends Bar {
  [super.something]() {}
}

[ChadKillingsworth]

No - need to recognize access to super within a computed property function:

class Foo extends Bar {
  [someThing]() {
    super.otherThing();
  }
}

[ChadKillingsworth]

I believe it was this test case: https://github.com/google/closure-compiler/pull/2418/files#diff-8cd1c911f8bd71b40937a5cdb2dbca85R1025

[brad4d]

Before doing this PR, I think we'd better have one that removes support for calling super() in a non-constructor method.

[ChadKillingsworth]

Submitted as #2452

[brad4d]

I think this is going too far.
If you have super.foo.bar.baz(), we only need to go as far as super.foo to determine what to do.

[ChadKillingsworth]

Currently waiting on #2419 and #2452

[brad4d]

This should be unblocked now that #2452 is closed.
@ChadKillingsworth I'll take another look once you've resolved conflicts and addressed the remaining review comments.

[ChadKillingsworth]

@brad4d ready for review again.

[brad4d]

The Travis failure was probably because our build was broken over the weekend.
It's fixed now, but I guess it doesn't automatically rerun.

[ChadKillingsworth]

You can trigger travis to rerun by closing then re-opening a PR.

[brad4d]

importing and testing...

[brad4d]

primary testing looks good
scheduling a 'test all the things' run now

[brad4d]

Tests looking good.
Sent to @MatrixFrog for internal review.

[brad4d]

Adding tests for access to a property defined with a getter and a setter before submitting.

[brad4d]

@ChadKillingsworth
I've added a couple of tests and pushed them back to you.
The runtime test shows that things aren't quite right yet.
The unit test I believe shows why.
The super transpilation here is causing the super setter to modify the prototype object.

[brad4d]

@ChadKillingsworth
Transpiling super.p = strikes me as tricky to get right and rarely useful to do anyway.
Perhaps you'd prefer to just add a CANNOT_CONVERT_YET error message for that case?

[MatrixFrog]

I would lean toward CANNOT_CONVERT rather than CANNOT_CONVERT_YET but I may be too much of a pessimist

[ChadKillingsworth]

I've got code that depends on transpiling super properties - and polymer uses it. It's not that hard to fix, but it'll probably need a runtime helper injected.

I'll work on it this week.

[ChadKillingsworth]

Disallowed assigning to a super property. @brad4d I assume you'll need to fix the runtime test. Since those don't run externally, I would just be guessing.

For posterity, here's how Babel transpiles assigning to a super property:

var _set = function set(object, property, value, receiver) {
  var desc = Object.getOwnPropertyDescriptor(object, property);
  if (desc === undefined) {
    var parent = Object.getPrototypeOf(object);
    if (parent !== null) {
      set(parent, property, value, receiver);
    }
  } else if ("value" in desc && desc.writable) {
    desc.value = value;
  } else {
    var setter = desc.set;
    if (setter !== undefined) {
      setter.call(receiver, value);
    }
  }
  return value;
};

Foobar.prototype.someMethod() {
  _set(Foobar.prototype.__proto__ || Object.getPrototypeOf(Foobar.prototype),
      "someprop", "someval", this);
}

[brad4d]

Imported.
Working on runtime_test and running tests.

[brad4d]

submitted internally
should be in the next push to github