Delete should return false if an element doesn't exist in a set.
ECMA_VALUE_EMPTY wasn't checked in case of a deleted property.
JerryScript-DCO-1.0-Signed-off-by: Daniel Balla dballa@inf.u-szeged.hu
ES5.1 15.9.1.15 Note1 defines that 24:00 is same as 0:00
of the next day. The spec explicitly doesn't mention that
24:01 should be invalid, but it should be self-evident.
(FireFox and Chrome also refuses times bigger than 24:00)
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
The implementation was incorrect for negative years and years bigger than 9999.
-1 was 000/ because the negative (year%10) was added to '0' character, years
bigger than 9999 was truncated to 4 digits.
ES5.1 15.9.1.15.1 defines extended years format with 6 digits, but toString()
and toISOString() sections don't mention anything about extended years. ES6
20.3.4.3 already clarifies that Date.prototype.toISOString() should use this
extended year format if it is necessary.
Changes:
- Date.prototype.toString() uses 4 digits for years by default, 5 or 6 if it
is necessary and put '-' sign for negative years, no sign for positive years.
Date.prototype.toString() was implementation dependent until ES9, but ES9
already specify exactly this format.
- Date.prototype.toISOString() uses fixed 4 digits for years 0 - 9999,
otherwise sign + 6 digits (extended years).
- Tests added for corner cases.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
ES5.1 15.9.4.2 specifies that Date.parse (string) has to accept
at least Date Time String Format: YYYY-MM-DDTHH:mm:ss.sssZ. But
the spec allows implementation-specific fallbacks. Additionally
ES5.1 15.9.1.15.1 specifies Extended years format, but isn't
explicitly required to be accepted by Date.parse. But ES6 already
clarified that Date.parse has to accept extended years format too.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
Fixes#3129
We need to check if we use the lastIndexOf method and if the second
argument is a number, negative, and its absolute value is bigger
than the length, then we should return with -1.
JerryScript-DCO-1.0-Signed-off-by: Adam Szilagyi aszilagy@inf.u-szeged.hu
After changing the lexing position, the current
position of the scanner info must be moved as well.
Fixes#3101Fixes#3102
JerryScript-DCO-1.0-Signed-off-by: Zoltan Herczeg zherczeg.u-szeged@partner.samsung.com
We should check if the start index is equal or greater than the end index,
if thats the case, we should return with the original typedArray.
Fixes#3107
JerryScript-DCO-1.0-Signed-off-by: Adam Szilagyi aszilagy@inf.u-szeged.hu
When popping the last element from a fast array the underlying buffer must be released.
This patch fixes#3106.
JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik frobert@inf.u-szeged.hu
The patch also checks whether pre-scanning is successful when scanning is,
so no need for explicit pre-scanner checks anymore.
JerryScript-DCO-1.0-Signed-off-by: Zoltan Herczeg zherczeg.u-szeged@partner.samsung.com
The algorithm is based on ECMA-262 v6, 22.2.3.27
Co-authored-by: Tibor Dusnoki tdusnoki@inf.u-szeged.hu
JerryScript-DCO-1.0-Signed-off-by: Adam Szilagyi aszilagy@inf.u-szeged.hu
The function names of classes were incorrectly parsed.
Also made the parsing more strict (more issues were captured by the pre-scanner).
Fixes#3088Fixes#3089
JerryScript-DCO-1.0-Signed-off-by: Zoltan Herczeg zherczeg.u-szeged@partner.samsung.com
The scanner was an on-demand tool of the parser, which was triggered by certain
statements. After the rework, the scanner runs only once, and collects all information.
This information is passed to the parser.
JerryScript-DCO-1.0-Signed-off-by: Zoltan Herczeg zherczeg.u-szeged@partner.samsung.com
The old last element should be released before reallocating the underlying buffer
JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik frobert@inf.u-szeged.hu
Fast mode access arrays must be converted back to normal if the array hole count reaches the limit during the initializtaion.
This patch fixes#3075.
JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik frobert@inf.u-szeged.hu
In case of TypedArrays which were constructed with an ArrayBuffer
the `slice` method incorrectly added the `byteOffset` value of
when the elements were copied.
There is no need to add the `byteOffset` value for the ArrayBuffer's
contents pointer as it is already added by the `ecma_typedarray_get_buffer`
call.
JerryScript-DCO-1.0-Signed-off-by: Peter Gal pgal.u-szeged@partner.samsung.com
The "super prop ref" flag is incorrectly used at multiple expressions
as it was only cleared if there was an assignment operation.
JerryScript-DCO-1.0-Signed-off-by: Peter Gal pgal.u-szeged@partner.samsung.com
Since fast access mode arrays can be part of the prototype chain these objects must be handed separately.
This patch fixes#3050.
JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik frobert@inf.u-szeged.hu
The algorithm's are based on ECMA-262 v6, 22.2.3.5 and 22.2.3.23
Co-authored-by: Tibor Dusnoki tdusnoki@inf.u-szeged.hu
JerryScript-DCO-1.0-Signed-off-by: Adam Szilagyi aszilagy@inf.u-szeged.hu