The addition of an is_generator parameter broke this, as is_strict was
being passed in, causing an assertion.
This is being addressed by changing it to an enum in #7981, but in the
meantime let's just fix these two cases.
20.5.1.1 Error ( message )
When the Error function is called with argument message, the
following steps are taken:
[...]
3b. Let msgDesc be the PropertyDescriptor {
[[Value]]: msg,
[[Writable]]: true,
[[Enumerable]]: false,
[[Configurable]]: true
}.
3c. Perform ! DefinePropertyOrThrow(O, "message", msgDesc).
The FunctionPrototype is correct for ErrorConstructor itself:
20.5.2 Properties of the Error Constructor
The Error constructor:
- has a [[Prototype]] internal slot whose value is
%Function.prototype%.
However, not for all the other "NativeError" constructors:
20.5.6.2 Properties of the NativeError Constructors
Each NativeError constructor:
- has a [[Prototype]] internal slot whose value is %Error%.
Non-RangeError exceptions can be thrown by user implementations of
valueOf (which are called by to_index), and the specification disallows
changing the type of the thrown error.
The second argument (the default constructor) and the return value have
to be constructors (as a result functions), so we can require that
explicitly by using appropriate types.
The `c_iflag` and `c_oflag` fields were swapped in the source code which
caused the bit values to be interpreted as the wrong flag. It was a
stupid mistake on my part.
This patch adds a CallType to the Bytecode::Op::Call instruction,
which can be either Call or Construct. We then generate Construct
calls for the NewExpression AST node.
When executed, these get fed into VM::construct().
This adds a new PushLexicalEnvironment instruction that creates a new
LexicalEnvironment and pushes it on the VM's scope stack.
There is no corresponding PopLexicalEnvironment instruction yet,
so this will behave incorrectly with let/const scopes for example.
This replaces Bytecode::Op::EnterScope with a new NewFunction op that
instantiates a ScriptFunction from a given FunctionNode (AST).
This is then used to instantiate the local functions directly from
bytecode when entering a ScopeNode. :^)
These will be partly handled by the relevant ScopeNode due to
hoisting, same basic idea as function declarations.
VariableDeclaration needs to do some work, but let's stub it out
first and start empty.
EnterUnwindContext pushes an unwind context (exception handler and/or
finalizer) onto a stack.
LeaveUnwindContext pops the unwind context from that stack.
Upon return to the interpreter loop we check whether the VM has an
exception pending. If no unwind context is available we return from the
loop. If an exception handler is available we clear the VM's exception,
put the exception value into the accumulator register, clear the unwind
context's handler and jump to the handler. If no handler is available
but a finalizer is available we save the exception value + metadata (for
later use by ContinuePendingUnwind), clear the VM's exception, pop the
unwind context and jump to the finalizer.
ContinuePendingUnwind checks whether a saved exception is available. If
no saved exception is available it jumps to the resume label. Otherwise
it stores the exception into the VM.
The Jump after LeaveUnwindContext could be integrated into the
LeaveUnwindContext instruction. I've kept them separate for now to make
the bytecode more readable.
> try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4
1:
[ 0] EnterScope
[ 10] EnterUnwindContext handler:@4 finalizer:@3
[ 38] EnterScope
[ 48] LoadImmediate 1
[ 60] NewString 1 ("x")
[ 70] Throw
<for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here>
2:
[ 0] LoadImmediate 4
3:
[ 0] EnterScope
[ 10] LoadImmediate 3
[ 28] ContinuePendingUnwind resume:@2
4:
[ 0] SetVariable 0 (e)
[ 10] EnterScope
[ 20] LoadImmediate 2
[ 38] LeaveUnwindContext
[ 3c] Jump @3
String Table:
0: e
1: x
These are pretty common on older LGA1366 & LGA1150 motherboards.
NOTE: Since the registers datasheets for all versions of the chip
besides versions 1 - 3 are still under NDAs i had to collect
several "magical vendor constants" from the *BSD driver and the
linux driver that i was not able to name verbosely, and as such
these are labeled with the comment "vendor magic values".
This commit adds support for these escape sequences that are used for
scrolling multiple lines at once. In the current, unoptimized
implementation, these just call the `scroll_left` and `scroll_right`
APIs multiple times.
It's a VT420 feature.
If we do not flush the dirty lines, characters typed in canonical mode
only appear after the virtual console has been switched away from, or
the application has been killed. Instead, we now immediately perform the
flush.
If lines are removed from the tail of the scrollback buffer, the
previous line indices will refer to different lines; therefore we need
to offset them.
These escape sequences are the horizontal scrolling equivalents of `IND`
and `RI`. Normally, they move the cursor forward or backward. But if
they hit the margins (which we just treat as the first and last
columns), they scroll the line.
Another VT420 feature done.
This commit implements the left/right scrolling used in the `ICH`/`DCH`
escape sequences for `VirtualConsole`. This brings us one step closer to
VT420/xterm compatibility.
We can now finally remove the last escape sequence related `ifdef`s.
Previously, this was done by telling the client to put a space at each
character in the range. This was inefficient, because a large number of
function calls took place and incorrect, as the ANSI standard dictates
that character attributes should be cleared as well.
The newly added `clear_in_line` function solves this issue. It performs
just one bounds check when it's called and can be implemented as a
pretty tight loop.
Previously, we would remove lines from the buffer, create new lines and
insert them into the buffer when we scrolled. Since scrolling does not
always happen at the last line, this meant `Line` objects were
pointlessly moved forwards, and then immediately backwards.
We now swap them in-place and clear those lines that are "inserted". As
a result, performance is better and scrolling is smoother in `vim` and
`nano`.
The `num` parameter should be treated as an offset from the cursor
position, not from the beginning of the line. The previous behavior
caused fragments of previous lines to be visible when moving the entire
buffer in vim (e.g. with `gg` and `G`).
The debug messages I used while fixing it are also included in this
commit. These will help diagnose further issues if they arise.
This commit cleans up some of the `#ifdef`-ed code smell in
`Terminal`, by extending the scroll APIs to take a range of lines as a
parameter. This makes it possible to use the same code for `IL`/`DL` as
for scrolling.
Note that the current scrolling implementation is very naive, and does
many insertions/deletions in the middle of arrays, whereas swaps should
be enough. This optimization will come in a later commit.
The `linefeed` override was removed from `VirtualConsole`. Previously,
it exhibited incorrect behavior by moving to column 0. Now that we use
the method defined in `Terminal`, code which relied on this behavior
stopped working. We go instead go through the TTY layer which handles
the various output flags. Passing the input character-by-character
seems a bit excessive, so a fix for it will come in another PR.
Previously, entering too big counts for these commands could cause a
wrap-around with the cell indices.
Also, we are now correctly copying the cell attributes as well as the
code point.
More specifically, Array.prototype.splice. Additionally adds a missing
exception check to the array creation and a link to the spec.
Fixes create-non-array-invalid-len.js in the splice tests in test262.
This test timed out instead of throwing an "Invalid array length"
exception.
