The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
For various statements the spec states:
Return NormalCompletion(empty).
In those cases we have been returning undefined so far, which is
incorrect.
In other cases it states:
Return Completion(UpdateEmpty(stmtCompletion, undefined)).
Which essentially means a statement is evaluated and its completion
value returned if non-empty, and undefined otherwise.
While not actually noticeable in normal scripts as the VM's "last value"
can't be accessed from JS code directly (with the exception of eval(),
see below), it provided an inconsistent experience in the REPL:
> if (true) 42;
42
> if (true) { 42; }
undefined
This also fixes the case where eval() would return undefined if the last
executed statement is not a value-producing one:
eval("1;;;;;")
eval("1;{}")
eval("1;var a;")
As a consequence of the changes outlined above, these now all correctly
return 1.
See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation,
"NOTE 2".
Fixes#3609.
With one small exception, this is how we've been using this API already,
and it makes sense: a Program is just a ScopeNode with any number of
statements, which are executed one by one. There's no explicit return
value at the end, only a completion value of the last value-producing
statement, which we then access using VM::last_value() if needed (e.g.
in the REPL).
This patch makes tgamma use an approximation that is more accurate with
regards to floating point arithmetic, and fixes some issues when tgamma
was called with positive integer values.
It also makes lgamma set signgam to the correct value, and makes its
return value be more inline with what the C standard defines.
This ensures that when a DeflateCompressor stream is cleared of any
errors its underlying wrapped streams (InputBitStream/InputMemoryStream)
will be cleared as well and wont fail a VERIFY on destruction.
There's a bit more nuance to how this should really work, but let's at
least make sure we execute <script> elements if you insert them into
the document.
Use the new CustomGet/CustomPut wrapper mechansim to intercept gets and
puts on CSSStyleDeclaration objects. This allows content to get and set
individual CSS properties from JavaScript. :^)
You can now set the CustomGet and/or CustomPut extended attributes on
an interface. This allows you to override JS::Object::get/put in the
wrapper class.
https://tc39.es/ecma262/#sec-function.prototype.tostring - this is how
the spec wants us to do it. :^)
Also change the function name behaviour to only provide a name for
NativeFunctions, which matches other engines - presumably to not expose
Proxy objects, and to prevent "function bound foo() { [native code] }".
There are three JS::Function types that are not ScriptFunction:
NativeFunction, BoundFunction and ProxyObject. We were only checking for
the first two when determining whether to reconstruct the function's
source code, which was leading to a bad cast to ScriptFunction.
Since only ScriptFunction has the [[SourceText]] internal slot, I simply
swapped the branches here.
Fixes#5775.
- We were not passing the to_string()'d argument to the exec function
but the original argument
- We were leaking an empty value in two cases, which almost certainly
will crash something down the line
- We were not checking for exceptions after to_string() and get(), which
both may throw. If the getter is an accessor, it'll assert upon being
called with the VM already storing an exception.
Very incompressible data could sometimes produce no backreferences
which would result in no distance huffman code being created (as it
was not needed), so VERIFY the code exists only if it is actually
needed for writing the stream.
