Writing to array entries using Object.defineProperty() (or
Object.defineProperties()) now causes an array part to be
abandoned. This is certainly not preferable behavior, but
not a 1.0 release blocker, so fixing this can be done in 1.1.
Push the internal Object.defineProperty() function only once outside the
loop to work better with large Object.defineProperty() calls. The
different is quite small in practice.
It would be better to avoid creating a function object in the first place,
but since we call Object.defineProperty() internally we need the original,
unchanged Object.defineProperty() in case the user has overwritten it.
The Array exotic [[DefineOwnProperty]] must capture and reject such
writes with RangeError. Handling for this is integrated into Duktape's
"putprop" algorithm and also defineProperty(). Other internals must
either use "putprop" or implement a similar check carefully.
Checks various base values for which the special behavior should or
should not apply. Also tests various target values for which the
behavior should or should not apply.
When a base object has the special [[Get]] behavior described in E5.1
Section 15.3.5.4 or 10.6 for the "caller" property, there is a question
whether a TypeError is thrown when the "caller" property value is a
bound strict function (or only when the value is a non-bound strict
function).
This commit changes the behavior so that a TypeError is also thrown
when the "caller" value is a bound function, by ensuring that strict
bound functions have the "strict" internal flag set.
The algorithm to iterate for a tzoffset when given local time parts can
start alternating between two values on some DST transitions. This diff
adds explicit support to delete such a loop and consistently select the
higher tzoffset in this case. This makes Duktape match Rhino/V8 behavior
for such ambiguous cases.
These cases arise when a local time which can never exist is used. For
instance, when going from non-DST to DST, there is one hour of local time
which is never used by actual timestamps. Specifying such as time for
the Date constructor has no well defined result.
The algorithm is now combined into the timeval-to-parts algorithm because
it's convenient for the call site. The equivalent year algorithm needs
to figure out the days-since-epoch for Jan 1 of the input year, which the
timeval-to-parts algorithm already knows.
It may be that equivalent year mapping is needed elsewhere too, e.g.
Windows time algorithms which may need it outside of timeval-to-parts
conversion (e.g. the current Windows tzoffset algorithm does not use
timeval-to-parts). A separate or shared implementation can then be
written.
There was a bug in the earlier draft of the equivalent year algorithm: the
weekday must be for the start of the input year, not for the day referred
to by the input timestamp.
Use an iterative algorithm to get the proper tzoffset when creating a
Date from local time parts. Not sure if this is the best approach but
currently the only tzoffset primitive available is tzoffset-for-utctime
(more accurately, tzoffset-for-timevalue).