1287342 - Allow native constructors to opt into returning primitives

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[(no longer active)]

In order to implement the V8 semantics, in some cases we need a native constructor to return a primitive value without this assertion <https://dxr.mozilla.org/mozilla-central/source/js/src/jscntxtinlines.h#288> going off.

I'm trying to find a good way to relax that assertion when the embedder explicitly wants to allow native ctors to return primitives.  I tried to add a flag to JSFunction to denote that the assertion should be bypassed but there are no free flags left there.

Jason, can you think of a good solution here?

Comment 1

[Jeff Walden [:Waldo]]

V8 fails to implement core ES6 semantics.  We should not be following it.

Per ES6 6.1.7.3, various object internal methods must implement certain invariants -- things like you can't define a property on an object that's non-extensible, can't appear to change a property that's been viewed as non-configurable (except in its value or writability), etc.  From that section:

"""
The Internal Methods of Objects of an ECMAScript engine must conform to the list of invariants specified below.  Ordinary ECMAScript Objects as well as all standard exotic objects in this specification maintain these invariants.

Any implementation provided exotic objects must also maintain these invariants for those objects.

An implementation must not allow these invariants to be circumvented in any manner such as by providing alternative interfaces that implement the functionality of the essential internal methods without enforcing their invariants.

...

[[Construct]] ( )
  * The Type of the return value must be Object.
"""

ES6 is crystal-clear that it is forbidden to let the embedder get away with it when he "explicitly wants to allow native ctors to return primitives".  We're doing the right thing here (with the caveat that we consider JSNative to be trustworthy and require embedders not return bad values).  V8 is totally wrong.

Comment 2

[(no longer active)]

OK, your argument makes perfect sense.  I'm happy to not implement this part of the API semantics (which is a small edge case, FWIW, and probably not all that important given that a fix to the embedder code is trivial.)

Thanks!