Allow null or undefined in Reference Records

[codehag]

For review by @jorendorff.

I checked all locations where .[[Base]] is used. There don't appear to be locations as far as I can tell, where this change will be an issue, see https://searchfox.org/ecma262/search?q=.%5B%5BBase%5D%5D&path=

In this cases, null and undefined is handled implicitly: IsUnresolvableReference and this change wouldn't result in a change in behavior.

The same is true of IsPropertyReference, but I think we want to change it, because otherwise we would fall back on thinking this is an environment record. See the code around these instances. But, if we change to return true for null or undefined, we will be caught by ToObject as in these cases.

I am not as sure about ToObject -- this will change at which point we throw (which is, I guess, the point).

In all of these cases, we follow with an assertion that the value is an environment record

I may have missed something that needs to be changed though, let me know if that is the case.

[jorendorff]

• I can't tell if MakeSuperPropertyReference needs the same treatment. Maybe someone more familiar with the super bits of the spec can say.

• I gather the intent is that property expressions produce property References and identifiers produce environment References—it's a static invariant.

  I think the language of the check in IsPropertyReference should be changed to:

  2. If V.[[Base]] is an Environment Record, return false; otherwise return true.

• In GetValue, the call to "! ToObject" must be changed to "? ToObject" since it can now fail.

• Same thing in PutValue.

• Same thing in Evaluation for delete expressions, step 5.b.

[jorendorff]

OK, I think MakeSuperPropertyReference needs the same change, for consistency.

But there is something I'm confused about.

There are actually two cases where the RequireObjectCoercible check in MakeSuperPropertyReference could fail:

• One is if env.GetSuperBase() returns null in step 3. I think this is what happens in this example:

  class C {
    set v(x) {
      super.v = console.log("GOT HERE");
    }
  }
  new C().v = 37;
  

• The other is if env.GetSuperBase() returns undefined. I don't know how this is possible.

[codehag]

The other is if env.GetSuperBase() returns undefined. I don't know how this is possible.

I don't know if it is? In the code above env.GetSuperBase() we assert that it is not undefined, so I am not sure how we can get to that. Maybe this is some older text that made more sense before? I will see if I can get more eyes on it. I made the change in any case.

[caiolima]

I spent some time investigating the impact of such change and couldn't find anything strange on super.prop cases, nor delete or typeof operators.

The other is if env.GetSuperBase() returns undefined. I don't know how this is possible.

I don't know if it is? In the code above env.GetSuperBase() we assert that it is not undefined, so I am not sure how we can get to that. Maybe this is some older text that made more sense before? I will see if I can get more eyes on it. I made the change in any case.

Looking into MakeSuperPropertyReference we can have a clue that if we ever get env.GetSuperBase() to return undefined, it's a bug, since env.HasSuperBinding() would return false when we get [[HomeObject]] to be undefined. I'm also not able to think in a way where we could have super.prop, where super evaluates to undefined.

As a matter of clarification, I managed to make super evaluate to null with this code:

class C {
    static access() {
        super.foo = print('blah');
    }
}

Object.setPrototypeOf(C, null);
C.access();

Regarding typeof operation, since it relies on GetValue(V) and the PR includes changes to it, we should not have troubles there.
Overall, I think such change makes sense and LGTM.