1515167 - Fix fallback prototype behavior in remaining cases

Status: RESOLVED DUPLICATE of bug 1288457

(Core :: JavaScript Engine, enhancement, P3)

Description

[Jason Orendorff [:jorendorff]]

test262 has a few tests (which we fail) for the case where NewTarget is

* a bound function
* %GeneratorFunction%

but not for

* %AsyncFunction%
* %AsyncGeneratorFunction%
* places where we call CreateThis() or CreateThisForFunction(),
    including one call in BaselineIC.cpp (!)
* ReadableStreamDefaultReader
* the various Intl constructors, like Intl.PluralRules

Comment 1

[Jason Orendorff [:jorendorff]]

To clarify: bug 1317416 is about the corner case where

* you've written a subclass
* that extends a builtin constructor
* from another realm
* and you've set the subclass's .prototype property to null or some other non-object value

Already ridiculous. This bug is about the subset of those cases not already being fixed in bug 1317416, mainly cases involving builtin constructors that aren't direct properties of the global object (hence %GeneratorFunction% and so on).

Comment 2

[Jason Orendorff [:jorendorff]]

(Following up on conversation in bug 1317416)

We have this code in js::GetPrototypeFromConstructor:

  } else if (intrinsicDefaultProto == JSProto_Null) {
    // Bug 1317416. The caller did not pass a reasonable JSProtoKey, so let the
    // caller select a prototype object. Most likely they will choose one from
    // the wrong realm.
    proto.set(nullptr);
  } else {
    // Step 4.a: Let realm be ? GetFunctionRealm(constructor);
    JSObject* unwrappedConstructor = CheckedUnwrap(newTarget);
    if (!unwrappedConstructor) {
      ReportAccessDenied(cx);
      return false;
    }

    ...
  }

Both of these cases have bugs.

In the first, the bug is that the caller didn't pass in a good JSProtoKey, and that's because we currently don't have a JSProtoKey enumerator for every prototype we want to get using this function.

In the else branch, the bug is that we don't do a full implementation of GetFunctionRealm. I can't remember why not. Maybe for some reason I was thinking newTarget had to be an actual Function (or CCW to one), but it can be any object that passes IsConstructor.

Comment 3

[Jason Orendorff [:jorendorff]]

(In reply to Jason Orendorff [:jorendorff] from comment #0)

but not for

• %AsyncFunction%
• %AsyncGeneratorFunction%
• the various Intl constructors, like Intl.PluralRules

The test262 import I'm doing right now adds tests (which we also fail) for these three cases.

Comment 4

[André Bargull [:anba]]

bug 1288457 should have fixed these cases. Perhaps this was tested with an old build?

Comment 5

[Jason Orendorff [:jorendorff]]

Yep, this is fixed. Two tests still fail for an unrelated reason (bug 1591099).