Commit graph

71 commits

Author SHA1 Message Date
davidot
def8b44c40 LibJS: Add support for public fields in classes 2021-09-01 13:39:14 +01:00
davidot
020bfc9d93 LibJS: Parse and partially execute import and export statements
We produce the import and export entries as per the spec. However we do
not yet verify that named things that are exported are declared
somewhere.
2021-08-15 23:51:47 +01:00
davidot
7613c22b06 LibJS: Add a mode to parse JS as a module
In a module strict mode should be enabled at the start of parsing and we
allow import and export statements.
2021-08-15 23:51:47 +01:00
Timothy Flynn
f1dd770a8a LibJS: Parse RegExp literals at AST creation time, not execution time
The spec requires that invalid RegExp literals must cause a Syntax Error
before the JavaScript is executed. See:
https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors

This is explicitly tested in the RegExp/property-escapes test262 tests.
For example, see unsupported-property-Line_Break.js:

    $DONOTEVALUATE();
    /\p{Line_Break}/u;

That RegExp literal is invalid because Line_Break is not a supported
Unicode property. $DONOTEVALUATE() just throws an exception when it is
executed. The test expects that this file will fail to be parsed.

Note that RegExp patterns can still be parsed at execution time by way
of "new RegExp(...)".
2021-07-30 21:26:31 +01:00
Ali Mohammad Pur
049e210cfa LibJS: Rework Identifier parsing to match the spec more closely 2021-07-11 21:41:54 +01:00
Ali Mohammad Pur
77a5144264 LibJS: Add support for binding patterns in catch clauses
`try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate
it correctly :^)
2021-07-11 21:41:54 +01:00
Ali Mohammad Pur
1a9518ebe3 LibJS: Implement parsing and evaluation for AssignmentPatterns
e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 21:41:54 +01:00
Ali Mohammad Pur
7fc6cd6b20 LibJS: Allow 'name = value' in object literals as the spec does
Currently, these are _always_ a syntax error, future commits will make
it valid in certain contexts.
2021-07-11 21:41:54 +01:00
Hendi
0dc4e722e6 LibJS: Make FunctionExpression more spec-compliant 2021-07-07 23:31:51 +01:00
Hendi
37c4fbb6ca LibJS: Don't hoist functions under certain circumstances
When a lexical declaration with the same name as a function exists,
the function is not hoisted (annex B).
2021-07-06 22:55:16 +01:00
Linus Groh
3faeabf1dc Revert "LibJS: Don't hoist functions under certain circumstances"
This reverts commit 3411d50737.

It was causing LeakSanitizer on CI to fail, possibly due to a circular
reference.
2021-07-06 13:25:37 +01:00
Hendi
3411d50737 LibJS: Don't hoist functions under certain circumstances
When a lexical declaration with the same name as a function exists,
the function is not hoisted (annex B).
2021-07-06 00:15:37 +01:00
Hendi
38fd980b0c LibJS: Improve function hoisting across blocks
The parser now keeps track of a scope chain so that it can hoist
function declarations to the closest function scope.
2021-07-06 00:15:37 +01:00
Hendi
72f8d90dc5 LibJS: Remove variables from FunctionNode
They weren't consumed anywhere outside the AST and went
against the usual concept of having declaration in ScopeNode.
2021-07-06 00:15:37 +01:00
Andreas Kling
71fc7ac7ac LibJS: Make SuperCall a proper AST node and clean up evaluation 2021-07-02 19:39:09 +02:00
Andreas Kling
d81f4d5228 LibJS: NewExpression doesn't need compute_this_and_callee()
Now that NewExpression is separated from CallExpression, it doesn't
have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 18:43:25 +02:00
Andreas Kling
814549b846 LibJS: Split out NewExpression evaluation from CallExpression
This patch adds an override for NewExpression::execute() in the AST
interpreter to separate the logic from CallExpression. As a result,
both evaluation functions are simplified.

Both expressions are still largely non-conforming, but this makes
it easier to work on improving that since we can now deal with them
separately. :^)
2021-07-02 18:25:32 +02:00
Johan Dahlin
f6028c2534 LibJS: NewClass bytecode instruction
This adds a the NewClass bytecode instruction, enough of it
is implemented for it to show it in the bytecode (js -d).
2021-07-01 17:34:05 +02:00
Andreas Kling
bc1930e0e0 LibJS: Fix clang-tidy warnings in AST.h
- Add/remove `move()` as suggested.
- Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
Andreas Kling
8a3c9d9851 LibJS: Remove direct argument loading since it was buggy
The parser doesn't always track lexical scopes correctly, so let's not
rely on that for direct argument loading.

This reverts the LoadArguments bytecode instruction as well. We can
bring these things back when the parser can reliably tell us that
a given Identifier is indeed a function argument.
2021-06-22 22:20:17 +02:00
Matthew Olsson
df65ff8a1e LibJS: Add bytecode support for regexp literals 2021-06-21 00:28:07 +02:00
Matthew Olsson
ce04c2259f LibJS: Restructure and fully implement BindingPatterns 2021-06-19 09:38:26 +02:00
Ali Mohammad Pur
3194177dce LibJS: Correctly parse yield-from expressions
This commit implements parsing for `yield *expr`, and the multiple
ways something can or can't be parsed like that.
Also makes yield-from a TODO in the bytecode generator.
Behold, the glory of javascript syntax:
```js
// 'yield' = expression in generators.
function* foo() {
    yield
    *bar; // <- Syntax error here, expression can't start with *
}

// 'yield' = identifier anywhere else.
function foo() {
    yield
    *bar; // Perfectly fine, this is just `yield * bar`
}
```
2021-06-14 13:06:08 +01:00
Andreas Kling
481cef59b6 LibJS: Track which Identifier nodes refer to function arguments
This patch adds an "argument index" field to Identifier AST nodes.
If the Identifier refers to a function parameter in the currently
open function scope, we stash the index of the parameter here.

This will allow us to implement much faster direct access to function
argument variables.
2021-06-14 11:26:12 +02:00
Andreas Kling
095accd2b2 LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code 2021-06-13 19:11:29 +02:00
Ali Mohammad Pur
8b3f8879c1 LibJS: Use an enum class instead of 'bool is_generator'
This avoid confusion in the order of the multiple boolean parameters
that exist.
2021-06-11 19:42:58 +04:30
Marcin Gasperowicz
a64089092f LibJS: Implement bytecode generation for switch 2021-06-11 13:12:26 +02:00
Andreas Kling
af48a066c6 LibJS: Add bytecode generation for FunctionExpression :^) 2021-06-11 10:46:46 +02:00
Andreas Kling
749a3b9245 LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode
This will make it easier to write bytecode generation for function
expressions in just a moment.
2021-06-11 10:45:49 +02:00
Ali Mohammad Pur
b47246ec70 LibJS: Switch AST.{h,cpp} to east const 2021-06-11 00:30:09 +02:00
Ali Mohammad Pur
3234697eca LibJS: Implement generator functions (only in bytecode mode) 2021-06-11 00:30:09 +02:00
Andreas Kling
941be2dcc2 LibJS: Add empty bytecode generation for VariableDeclaration
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.
2021-06-10 21:59:49 +02:00
Gunnar Beutner
67cc31a74f LibJS: Implement bytecode generation for try..catch..finally
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
2021-06-10 21:59:46 +02:00
xyanrch
a0412e0d5e LibJS: Implement bytecode generation for BreakStatement 2021-06-10 21:48:20 +04:30
Gunnar Beutner
2d48fe894f LibJS: Generate bytecode for tagged template literals 2021-06-09 21:54:31 +02:00
Gunnar Beutner
b78f1c1261 LibJS: Generate bytecode for throw statements 2021-06-09 20:04:11 +02:00
Andreas Kling
59eedd6de0 LibJS: Implement bytecode generation for UpdateExpression :^)
Added Increment and Decrement bytecode ops to support this. Postfix
updates use a temporary register to preserve the original value.

Note that this patch only implements Identifier updates. Member
expression updates are a TODO.
2021-06-09 11:40:38 +02:00
Gunnar Beutner
a1e5711a27 LibJS: Generate bytecode for array expressions 2021-06-09 01:27:18 +02:00
Matthew Olsson
9bed2e4f4a LibJS: Introduce an accumulator register to Bytecode::Interpreter
This commit introduces the concept of an accumulator register to
LibJS's bytecode interpreter. The accumulator register is always
register 0, and most simple instructions use it for reading and
writing.

Not only does this slim down the AST, but it also simplifies a lot of
the code. For example, the generate_bytecode methods no longer need
to return an Optional<Register>, as any opcode which has a "return"
value will always put it into the accumulator.

This also renames the old Op::Load to Op::LoadImmediate, and uses
Op::Load to load from a register into the accumulator. There is
also an Op::Store to put the value in the accumulator into another
register.
2021-06-08 21:00:12 +02:00
Gunnar Beutner
75a12bc2b7 LibJS: Generate bytecode for template literals 2021-06-08 19:47:32 +02:00
Linus Groh
68ce69db88 LibJS: Add for loop bytecode generation 2021-06-08 11:59:32 +02:00
Gunnar Beutner
50ece3dd1b LibJS: Implement bytecode generation for BigInts 2021-06-08 10:57:28 +01:00
Luke
1dc31842cb LibJS: Add sequence expression bytecode generation 2021-06-08 11:20:10 +02:00
Luke
de3ee701ce LibJS: Add conditional expression bytecode generation
Or, by its more common name, the ternary operator :^)
2021-06-08 09:53:56 +01:00
Gunnar Beutner
6da587b59b LibJS: Implement bytecode ops for logical expressions 2021-06-08 10:42:45 +02:00
Gunnar Beutner
9e69ffc1b1 LibJS: Add bytecode generation for EmptyStatement 2021-06-07 20:06:46 +01:00
Linus Groh
2b8a2542a0 LibJS: Add bytecode generation for DebuggerStatement
No-op. :^)
2021-06-07 20:05:50 +01:00
Linus Groh
fa9bad912e LibJS: Add bytecode instructions for a bunch of unary operators
~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
Gunnar Beutner
8ed5b7dcfa LibJS: Add bytecode ops for loading boolean and null values 2021-06-07 20:26:45 +02:00
Andreas Kling
4bdfe73895 LibJS: Add basic support for "continue" in the bytecode VM
Unlike the convoluted unwind-until-scope-type mechanism in the AST
interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^)

We know where to jump based on a stack of "continuable scopes" that
we now maintain on the Bytecode::Generator as we go.

Note that this only supports bare "continue", not continue-with-label.
2021-06-07 18:11:59 +02:00