This is no longer required, since the variable scope is ended after
switching to the end block, which means that LeaveLexicalEnvironment
will always be generated instead of depending on the unwind mechanism
to handle it for us.
BlockDeclarationInstantiation takes as input the new lexical
environment that was created and checks if there is a binding for the
current name only in this new scope.
This allows shadowing lexical variables and prevents us crashing due to
an already initialized lexical variable in this case:
```js
let x = 1;
{
let x = 1;
}
```
An executable is generated for the top-level script and for each
function. Strict mode can only be changed with the first statement of
the top-level script and each function, which corresponds directly to
Executable.
The largest exponents we compute are on the order of 10^21 (governed by
the maximumSignificantDigits option, which has a max value of 21). That
is too large to fit into the i64 we were using when multiplying this
exponent by the value to be formatted.
Instead, split up the logic to multiply that value by this exponent
based on the value's underlying type:
Number: Do not cast the result of pow() to an i64, and perform the
follow-up multiplication with doubles.
BigInt: Do not use pow(). Instead, compute the exponent as a BigInt
from the start, then perform the follow-up multiplication with that
BigInt.
This is just a quick test that everything is working. Currently
it paints the gradients with the existing
painter.fill_rect_with_gradient(). This can only handle two-color
orthogonal gradients.
Step 19 of node removal was missing, which allows the mutations of the
descendants of the removed node to still be observed by the parent.
Step 20 of node removal queued the mutation record for the removed
node instead of it's parent. Since queuing takes place after the node
is removed from the tree, the mutation record would be lost as the only
inclusive ancestor of the node at this point is only the node itself.
Previously, changing a system theme with Calculator opened made buttons
with custom color not to update to the new theme - the background color
remained from the previous one.
This is because when setting the color, the widget has to copy the
current palette and modify the foreground color there, which means it
will no longer refer to the system theme and any change there will not
happen here.
Using colors from a system palette fixes this issue and makes buttons
look slightly different from what was here before. But that is because
they're now somewhat more integrated with the system themes! :^)
Type | Old color | New color role
---- | --------- | --------------
Numbers | "blue" | SyntaxNumber
Functions (sqrt, %) | "blue" | SyntaxFunction
Operators (+ - * /) | text-default | SyntaxOperator
Backspace, CE and C | "brown" | SyntaxControlKeyword
Memory operators, = | "red" | SyntaxPreprocessorValue
When |& is typed, stderr will be piped to stdout before the actual
piping happens. This behaves basically like a 2>&1 | (and the
underlying implementation transforms it to that anyway).
Previously we would erroneously apply the stylization to the whoever
called stylize next. Now we first check whether the span is non-empty
before stylizing. All non-empty spans must have at least one character
in them (end-exclusive).
Makes it much easier to scroll through the file while comparing to the
spec. Proposals are inserted alphabetically as that's where they will
likely end up once merged into the main spec.
Makes it much easier to scroll through the file while comparing to the
spec. Proposals are inserted alphabetically as that's where they will
likely end up once merged into the main spec.
