Commit graph

60 commits

Author SHA1 Message Date
Linus Groh
29964dc152 LibJS: Use TRY(push_execution_context()) in places where we can recover 2022-03-18 01:12:12 +01:00
Lenny Maiorani
d00b79568f Libraries: Use default constructors/destructors in LibJS
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules

"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
2022-03-16 16:19:40 +00:00
davidot
9264f9d24e LibJS+Everywhere: Remove VM::exception() and most related functions
This commit removes all exception related code:
Remove VM::exception(), VM::throw_exception() etc. Any leftover
throw_exception calls are moved to throw_completion.
The one method left is clear_exception() which is now a no-op. Most of
these calls are just to clear whatever exception might have been thrown
when handling a Completion. So to have a cleaner commit this will be
removed in a next commit.

It also removes the actual Exception and TemporaryClearException classes
since these are no longer used.

In any spot where the exception was actually used an attempt was made to
preserve that behavior. However since it is no longer tracked by the VM
we cannot access exceptions which were thrown in previous calls.
There are two such cases which might have different behavior:
- In Web::DOM::Document::interpreter() the on_call_stack_emptied hook
  used to print any uncaught exception but this is now no longer
  possible as the VM does not store uncaught exceptions.
- In js the code used to be interruptable by throwing an exception on
  the VM. This is no longer possible but was already somewhat fragile
  before as you could happen to throw an exception just before a VERIFY.
2022-02-08 09:12:42 +00:00
Andreas Kling
85cf80507f LibJS: Make ScriptOrModule use WeakPtr instead of raw pointers 2022-02-07 19:16:45 +01:00
davidot
779e677467 LibJS: Implement HostResolveImportedModule for LibJS
This loads modules with relative paths from the referencing module.
In this commit the only way to run a module is via the interpreter
which can link and evaluate a module (and all its dependencies).
2022-01-22 01:21:18 +00:00
davidot
57c5a59cab LibJS: Add ScriptOrModule to execution context and track it everywhere 2022-01-22 01:21:18 +00:00
Luke Wilde
631bbcd00a LibJS: Refactor interpreter to use Script and Source Text Modules
This also refactors interpreter creation to follow
InitializeHostDefinedRealm, but I couldn't fit it in the title :^)

This allows us to follow the spec much more closely rather than being
completely ad-hoc with just the parse node instead of having all the
surrounding data such as the realm of the parse node.

The interpreter creation refactor creates the global execution context
once and doesn't take it off the stack. This allows LibWeb to take the
global execution context and manually handle it, following the HTML
spec. The HTML spec calls this the "realm execution context" of the
environment settings object.

It also allows us to specify the globalThis type, as it can be
different from the global object type. For example, on the web, Window
global objects use a WindowProxy global this value to enforce the same
origin policy on operations like [[GetOwnProperty]].

Finally, it allows us to directly call Program::execute in perform_eval
and perform_shadow_realm_eval as this moves
global_declaration_instantiation into Interpreter::run
(ScriptEvaluation) as per the spec.

Note that this doesn't evalulate Source Text Modules yet or refactor
the bytecode interpreter, that's work for future us :^)

This patch was originally build by Luke for the environment settings
object change but was also needed for modules. So I (davidot) have
modified it with the new completion changes and setup for that.

Co-authored-by: davidot <davidot@serenityos.org>
2022-01-22 01:21:18 +00:00
Linus Groh
963b0f76cf LibJS: Remove now unused VM::{set_,}last_value()
This was effectively replaced by correct use of completions, including
UpdateEmpty semantics.
2022-01-08 23:43:03 +01:00
Linus Groh
eb60d16549 LibJS: Convert Interpreter::run() to ThrowCompletionOr<Value>
Instead of making it a void function, checking for an exception, and
then receiving the relevant result via VM::last_value(), we can
consolidate all of this by using completions.

This allows us to remove more uses of VM::exception(), and all uses of
VM::last_value().
2022-01-08 23:43:03 +01:00
Linus Groh
9d0d3affd4 LibJS: Replace the custom unwind mechanism with completions :^)
This includes:

- Parsing proper LabelledStatements with try_parse_labelled_statement()
- Removing LabelableStatement
- Implementing the LoopEvaluation semantics via loop_evaluation() in
  each IterationStatement subclass; and IterationStatement evaluation
  via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute()
- Updating ReturnStatement, BreakStatement and ContinueStatement to
  return the appropriate completion types
- Basically reimplementing TryStatement and SwitchStatement according to
  the spec, using completions
- Honoring result completion types in AsyncBlockStart and
  OrdinaryCallEvaluateBody
- Removing any uses of the VM unwind mechanism - most importantly,
  VM::throw_exception() now exclusively sets an exception and no longer
  triggers any unwinding mechanism.
  However, we already did a good job updating all of LibWeb and userland
  applications to not use it, and the few remaining uses elsewhere don't
  rely on unwinding AFAICT.
2022-01-06 12:36:23 +01:00
Linus Groh
da856d7742 LibJS: Update AST to use completions :^)
This is another major milestone on our journey towards removing global
VM exception state :^)
Does pretty much exactly what it says on the tin: updating
ASTNode::execute() to return a Completion instead of a plain value. This
will *also* allow us to eventually remove the non-standard unwinding
mechanism and purely rely on the various completion types.
2022-01-03 21:50:50 +01:00
Linus Groh
57de5056b6 LibJS: Convert push_execution_context() to ThrowCompletionOr 2021-11-14 16:14:38 +00:00
Linus Groh
58c34012dd LibJS: Pop execution context after running queued jobs in run()
These would crash starting with the next commit otherwise, calling a
function always requires the running execution context to exist.
2021-10-09 14:29:20 +01:00
davidot
ac808a261f LibJS: Fix that the interpreter did not clear the unwind status
This meant that if some program threw an uncaught exception VM still
had unwind_until set. This caused any further programs to not execute
correctly.
This will be fixed more thoroughly once we use Completions in the AST.

Fixes #10323
2021-10-03 17:42:05 +02:00
davidot
830ea0414c LibJS: Make scoping follow the spec
Before this we used an ad-hoc combination of references and 'variables'
stored in a hashmap. This worked in most cases but is not spec like.
Additionally hoisting, dynamically naming functions and scope analysis
was not done properly.

This patch fixes all of that by:
  - Implement BindingInitialization for destructuring assignment.
  - Implementing a new ScopePusher which tracks the lexical and var
    scoped declarations. This hoists functions to the top level if no
    lexical declaration name overlaps. Furthermore we do checking of
    redeclarations in the ScopePusher now requiring less checks all over
    the place.
  - Add methods for parsing the directives and statement lists instead
    of having that code duplicated in multiple places. This allows
    declarations to pushed to the appropriate scope more easily.
  - Remove the non spec way of storing 'variables' in
    DeclarativeEnvironment and make Reference follow the spec instead of
    checking both the bindings and 'variables'.
  - Remove all scoping related things from the Interpreter. And instead
    use environments as specified by the spec. This also includes fixing
    that NativeFunctions did not produce a valid FunctionEnvironment
    which could cause issues with callbacks and eval. All
    FunctionObjects now have a valid NewFunctionEnvironment
    implementation.
  - Remove execute_statements from Interpreter and instead use
    ASTNode::execute everywhere this simplifies AST.cpp as you no longer
    need to worry about which method to call.
  - Make ScopeNodes setup their own environment. This uses four
    different methods specified by the spec
    {Block, Function, Eval, Global}DeclarationInstantiation with the
    annexB extensions.
  - Implement and use NamedEvaluation where specified.

Additionally there are fixes to things exposed by these changes to eval,
{for, for-in, for-of} loops and assignment.

Finally it also fixes some tests in test-js which where passing before
but not now that we have correct behavior :^).
2021-09-30 08:16:32 +01:00
davidot
79caca8ca2 LibJS: Allow multiple labels on the same statement
Since there are only a number of statements where labels can actually be
used we now also only store labels when necessary.
Also now tracks the first continue usage of a label since this might not
be valid but that can only be determined after we have parsed the
statement.
Also ensures the correct error does not get wiped by load_state.
2021-09-30 08:16:32 +01:00
Andreas Kling
d294a3f54a LibJS: Avoid unnecessary HashMap growth in Interpreter::enter_scope()
Don't bother pre-allocating a hash map if we're not gonna put anything
into it anyway.
2021-09-28 22:32:40 +02:00
Andreas Kling
3252d984ae LibJS: Allow statements to have multiple labels
This is a curious thing that occurs more often than you'd think in
minified JavaScript:

    a: b: c: for (...) { ... break b; ... }
2021-09-26 18:24:19 +02:00
Linus Groh
e37cf73300 LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject
The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).

However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.

The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).

More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
2021-09-25 17:51:30 +02:00
Linus Groh
7b92889e6b LibJS: Change Interpreter::create_with_existing_{global_object => realm}
We need both a GlobalObject and Realm now, but can get the former from
the latter (once initialized).
This also fixes JS execution in LibWeb, as we failed to set the Realm of
the newly created Interpreter in this function.
2021-09-12 15:18:25 +02:00
Linus Groh
06e89311fa LibJS: Set the callee context's realm in prepare_for_ordinary_call()
This includes making FunctionObject::realm() actually return a Realm,
instead of a GlobalObject.
2021-09-12 11:10:20 +01:00
Linus Groh
f29a82dd84 LibJS: Move the GlobalEnvironment from GlobalObject to Realm
This is where the spec wants to have it. Requires a couple of hacks as
currently everything that needs a Realm actually has a GlobalObject, so
we need to go via the Interpreter.
2021-09-12 11:10:20 +01:00
Linus Groh
2b8d5696ab LibJS: Allocate a Realm next to GlobalObject in Interpreter::create()
Also pass a Realm reference to the Bytecode::Interpreter constructor,
just like we pass the GlobalObject.
2021-09-12 11:10:20 +01:00
Timothy Flynn
66264f7c2a LibJS: Change ExecutionContext's arguments list to a MarkedValueList
The test262 tests under RegExp/property-escapes/generated will invoke
Reflect.apply with up to 10,000 arguments at a time. In LibJS, when the
call stack reached VM::call_internal, we transfer those arguments from
a MarkedValueList to the execution context's arguments Vector.

Because these types differ (MarkedValueList is a Vector<Value, 32>), the
arguments are copied rather than moved. By changing the arguments vector
to a MarkedValueList, we can properly move the passed arguments over.

This shaves about 2 seconds off the following test262 test (from 15sec):
  RegExp/property-escapes/generated/General_Category_-_Decimal_Number.js
2021-08-10 23:07:50 +02:00
Brian Gianforcaro
53166c10ca LibJS: Remove unused header includes 2021-08-01 08:10:16 +02:00
Idan Horowitz
e3ef241108 LibJS: Remove the non-standard put helper and replace it's usages
This removes all usages of the non-standard put helper method and
replaces all of it's usages with the specification required alternative
or with define_direct_property where appropriate.
2021-07-06 14:20:30 +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
Andreas Kling
44221756ab LibJS: Drop "Record" suffix from all the *Environment record classes
"Records" in the spec are basically C++ classes, so let's drop this
mouthful of a suffix.
2021-07-01 12:28:57 +02:00
Andreas Kling
c8270dbe2e LibJS: Rename ScriptFunction => OrdinaryFunctionObject
These are basically what the spec calls "ordinary function objects",
so let's have the name reflect that. :^)
2021-06-27 22:36:04 +02:00
Andreas Kling
e59bf87374 Userland: Replace VERIFY(is<T>) with verify_cast<T>
Instead of doing a VERIFY(is<T>(x)) and *then* casting it to T, we can
just do the cast right away with verify_cast<T>. :^)
2021-06-24 21:13:09 +02:00
Andreas Kling
c2ad599783 LibJS: Rename CallFrame => ExecutionContext
This struct represents what the ECMAScript specification calls an
"execution context" so let's use the same terminology. :^)
2021-06-24 19:28:00 +02:00
Andreas Kling
1f8b6ac3c3 LibJS: Begin implementing GlobalEnvironmentRecord
These represent the outermost scope in the environment record
hierarchy. The spec says they should be a "composite" of two things:

- An ObjectEnvironmentRecord wrapping the global object
- A DeclarativeEnvironmentRecord for other declarations

It's not yet clear to me how this should work, so this patch only
implements the first part, an object record wrapping the global object.
2021-06-22 18:44:53 +02:00
Andreas Kling
1d20380859 LibJS: Split the per-call-frame environment into lexical and variable
To better follow the spec, we need to distinguish between the current
execution context's lexical environment and variable environment.

This patch moves us to having two record pointers, although both of
them point at the same environment records for now.
2021-06-22 18:44:53 +02:00
Andreas Kling
aabd82d508 LibJS: Bring function environment records closer to the spec
This patch adds FunctionEnvironmentRecord as a subclass of the existing
DeclarativeEnvironmentRecord. Things that are specific to function
environment records move into there, simplifying the base.

Most of the abstract operations related to function environment records
are rewritten to match the spec exactly. I also had to implement
GetThisEnvironment() and GetSuperConstructor() to keep tests working
after the changes, so that's nice as well. :^)
2021-06-22 18:44:53 +02:00
Andreas Kling
08510a0c80 LibJS: Rename VM::current_scope() => current_environment_record()
And rename some related functions that wrapped this as well.
2021-06-21 23:49:50 +02:00
Andreas Kling
d407f247b7 LibJS: Rename virtuals in EnvironmentRecord
This patch makes the following renames:

- get_from_scope() => get_from_environment_record()
- put_to_scope() => put_into_environment_record()
- delete_from_scope() => delete_from_environment_record()
2021-06-21 23:49:50 +02:00
Andreas Kling
5edd259b0a LibJS: Rename EnvironmentRecord::parent() => outer_environment()
This name matches the spec (corresponds to the [[OuterEnv]] slot.)
2021-06-21 23:49:50 +02:00
Andreas Kling
6c6dbcfc36 LibJS: Rename Environment Records so they match the spec :^)
This patch makes the following name changes:

- ScopeObject => EnvironmentRecord
- LexicalEnvironment => DeclarativeEnvironmentRecord
- WithScope => ObjectEnvironmentRecord
2021-06-21 23:49:50 +02:00
Matthew Olsson
ce04c2259f LibJS: Restructure and fully implement BindingPatterns 2021-06-19 09:38:26 +02:00
Idan Horowitz
de9fa6622a LibJS: Add the FinalizationRegistry built-in object
As well as the needed functionality in VM to enqueue and run cleanup
jobs for the FinalizationRegistry instances.
2021-06-15 23:59:21 +01:00
Idan Horowitz
6913f06b6f LibJS: Store and maintain an "execution generation" counter
This counter is increased each time a synchronous execution sequence
completes, and will allow us to emulate the abstract operations
AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 18:39:23 +01: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
Ali Mohammad Pur
3234697eca LibJS: Implement generator functions (only in bytecode mode) 2021-06-11 00:30:09 +02:00
Gunnar Beutner
319a60043b LibJS: Let the bytecode interpreter set the VM's last value 2021-06-10 21:47:25 +02:00
Andreas Kling
4bc98fd39f LibJS: Only "var" declarations go in the global object at program level
"let" and "const" go in the lexical environment.

This fixes one part of #4001 (Lexically declared variables are mixed up
with global object properties)
2021-06-09 23:25:16 +02:00
Idan Horowitz
af58779def LibJS: Return undefined from a with statement if no value was generated
Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 15:31:46 +01:00
Ali Mohammad Pur
7a00d6d9c8 LibJS: Implement destructuring assignments and function parameters 2021-05-29 23:02:23 +04:30
Linus Groh
a92dc4e30d LibJS: Ensure function declarations don't leak outside function scopes
When using VM::set_variable() to put the created ScriptFunction onto a
ScopeObject, we would previously unexpectedly reach the global object as
set_variable() checks each traversed scope for an existing Variable with
the given name - which would cause a leak of the inner function past the
outer function (we even had a test expecting that behaviour!). Now we
first declare functions (as DeclarationKind::Var) before setting them.
This will need some more work to make hoisting across non-lexical scopes
work, but it fixes this specific issue for now.

Fixes #6766.
2021-05-13 23:59:00 +01:00
Linus Groh
08373090ae LibJS: Add VM::on_call_stack_emptied callback
Instead of having to run queued promise jobs in LibWeb in various
places, this allows us to consolidate that into one function - this is
very close to how the spec describes it as well ("at some future point
in time, when there is no running execution context and the execution
context stack is empty, the implementation must [...]").

Eventually this will also be used to log unhandled exceptions, and
possibly other actions that require JS execution to have ended.
2021-04-24 20:11:04 +02:00
Brian Gianforcaro
1682f0b760 Everything: Move to SPDX license identifiers in all files.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.

See: https://spdx.dev/resources/use/#identifiers

This was done with the `ambr` search and replace tool.

 ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 11:22:27 +02:00