As mentioned on Discord earlier, we'll add these to all new functions
going forward - this is the backfill. Reasons:
- It makes you look at the spec, implementing based on MDN or V8
behavior is a no-go
- It makes finding the various functions that are non-compliant easier,
in the future everything should either have such a comment or, if it's
not from the spec at all, a comment explaining why that is the case
- It makes it easier to check whether a certain abstract operation is
implemented in LibJS, not all of them use the same name as the spec.
E.g. RejectPromise() is Promise::reject()
- It makes it easier to reason about vm.arguments(), e.g. when the
function has a rest parameter
- It makes it easier to see whether a certain function is from a
proposal or Annex B
Also:
- Add arguments to all functions and abstract operations that already
had a comment
- Fix some outdated section numbers
- Replace some ecma-international.org URLs with tc39.es
While this implementation should be complete it is based on HashMap's
iterator, which currently follows bucket-order instead of the required
insertion order. This can be simply fixed by replacing the underlying
HashMap member in Map with an enhanced one that maintains a linked
list in insertion order.
This will allow us to use these traits for other hash-based containers
(like Map). This commit also adds a special case for negative zero
values, because while the equality check used same_value_zero which is
negative/positive zero insensitive, the hash was not.
This counter is increased each time a synchronous execution sequence
completes, and will allow us to emulate the abstract operations
AddToKeptObjects & ClearKeptObjects efficiently.
This is very similar to Object::define_native_property, but here the
native functions are exported as standalone JS getter and setter
functions, instead of being transparently called by interactions with
the property.
Some of this stuff is already tested properly in the name and message
prototype tests, so let's focus on covering all error types here as well
instead.
The fact that they *are* subclasses is an implementation detail and
should not be highlighted. The spec calls these NativeErrors, so let's
use that.
Also added a comment explaining *why* they inherit from Error - I was
about to change that :^)
The property name in an object literal can either be a literal or a
computed name, in which case any AssignmentExpression can be used, we
now only parse AssignmentExpression instead of the previous incorrect
behaviour which allowed any Expression (Specifically, comma
expressions).
The addition of an is_generator parameter broke this, as is_strict was
being passed in, causing an assertion.
This is being addressed by changing it to an enum in #7981, but in the
meantime let's just fix these two cases.
20.5.1.1 Error ( message )
When the Error function is called with argument message, the
following steps are taken:
[...]
3b. Let msgDesc be the PropertyDescriptor {
[[Value]]: msg,
[[Writable]]: true,
[[Enumerable]]: false,
[[Configurable]]: true
}.
3c. Perform ! DefinePropertyOrThrow(O, "message", msgDesc).
The FunctionPrototype is correct for ErrorConstructor itself:
20.5.2 Properties of the Error Constructor
The Error constructor:
- has a [[Prototype]] internal slot whose value is
%Function.prototype%.
However, not for all the other "NativeError" constructors:
20.5.6.2 Properties of the NativeError Constructors
Each NativeError constructor:
- has a [[Prototype]] internal slot whose value is %Error%.
Non-RangeError exceptions can be thrown by user implementations of
valueOf (which are called by to_index), and the specification disallows
changing the type of the thrown error.
The second argument (the default constructor) and the return value have
to be constructors (as a result functions), so we can require that
explicitly by using appropriate types.
