While this implementation should be complete it is based on HashTable's
iterator, which currently follows bucket-order instead of the required
insertion order. This can be simply fixed by replacing the underlying
HashTable member in Set with an enhanced one that maintains a linked
list in insertion order.
This was missing from Value::is_array(), which is equivalent to the
spec's IsArray() abstract operation - it treats a Proxy value with an
Array target object as being an Array.
It can throw, so needs both the global object and an exception check
now.
Since DateTime stores months as 1 to 12, while JS accepts months as
0 to 11, we have to account for the difference (by subtracting or
adding 1) where appropriate.
This is now about as close to the spec as it gets - instead of querying
the |this| value inside of the function, we now pass it in from the
outside.
Also get rid of the oddly specific error messages, they're nice but
pretty inconsistent with most others. Let's prefer consistency and
simplicity for now.
Other than that, no functionality change.
This is a partial revert of commit 60064e2, which removed the validation
of RegExp flags during runtime and expected the parser to do that
exclusively - however this was not taking into account the RegExp()
constructor, which was subsequently crashing on invalid flags.
Also adds test for these constructor error cases, which were obviously
missing before.
Fixes#7042.
This patch changes the validation of RegExp flags (checking for
invalid and duplicate values) from a SyntaxError at runtime to a
SyntaxError at parse time - it's not something that's supposed to be
catchable.
As a nice side effect, this simplifies the RegExpObject constructor a
bit, as it can no longer throw an exception and doesn't have to validate
the flags itself.
The native C++ < and > operators won't handle this correctly, so the
result was different depending on the order of arguments. This is now
fixed by explicitly checking for positive and negative zero values.
Fixes#6589.
This was failing to take two things into account:
- When constructing a PropertyName from a value, it won't automatically
convert to Type::Number for something like string "0", even though
that's how things work internally, since indexed properties are stored
separately. This will be improved in a future patch, it's a footgun
and should happen automatically.
- Those can't be looked up on the shape, we have to go through the
indexed properties instead.
Additionally it now operates on the shape or indexed properties directly
as define_property() was overly strict and would throw if a property was
already non-configurable.
Fixes#6469.
This would crash on an undefined match (no match), since the matched
result was assumed to be a string (such as on discord.com). The spec
suggests converting it to a string as well:
https://tc39.es/ecma262/#sec-regexp.prototype-@@replace (14#c)
Fixes#6325
The JavaScript on the HTML Spec site that caused the crash is:
window.location.hash.substr(1)
Of course, window.location.hash can be the empty string. The spec allows
for calling substr(1) on an empty string, but our partial implementation
wasn't handling it properly.
Otherwise these will get their name/default message from the Error
prototype, and as a result would always just say "Error" in error
messages, not the specific type.
Something I missed in da177c6, now with tests. :^)
