Commit graph

71 commits

Author SHA1 Message Date
Andreas Kling
fbf9cb3387 WebContent+LibWeb+LibJS: Simplify injection of JS console globals
Instead of creating a new global object and proxying everything through
it, we now evaluate console inputs inside a `with` environment.

This seems to match the behavior of WebKit and Gecko in my basic
testing, and removes the ConsoleGlobalObject which has been a source of
confusion and invalid downcasts.

The globals now live in a class called ConsoleGlobalObjectExtensions
(renamed from ConsoleGlobalObject since it's no longer a global object).

To make this possible, I had to add a way to override the initial
lexical environment when calling JS::Interpreter::run(). This is plumbed
via Web::HTML::ClassicScript::run().
2022-12-09 18:51:03 +00:00
Andreas Kling
00c8f07192 LibJS: Make Script and Module GC-allocated
This ensures that code currently in any active or saved execution stack
always stays alive.
2022-09-06 00:27:09 +02:00
Linus Groh
275dea9d98 LibJS: Remove {Bytecode::,}Interpreter::global_object()
The basic idea is that a global object cannot just come out of nowhere,
it must be associated to a realm - so get it from there, if needed.

This is to enforce the changes from all the previous commits by not
handing out global objects unless you actually have an initialized
realm (either stored somewhere, or the VM's current realm).
2022-08-23 13:58:30 +01:00
Linus Groh
b345a0acca LibJS+LibWeb: Reduce use of GlobalObject as an intermediary
- Prefer VM::current_realm() over GlobalObject::associated_realm()
- Prefer VM::heap() over GlobalObject::heap()
- Prefer Cell::vm() over Cell::global_object()
- Prefer Wrapper::vm() over Wrapper::global_object()
- Inline Realm::global_object() calls used to access intrinsics as they
  will later perform a direct lookup without going through the global
  object
2022-08-23 13:58:30 +01:00
Linus Groh
56b2ae5ac0 LibJS: Replace GlobalObject with VM in remaining AOs [Part 19/19] 2022-08-23 13:58:30 +01:00
Linus Groh
5398dcc55e LibJS: Remove GlobalObject from execute() and related AST functions
This is a continuation of the previous four commits.

Passing a global object here is largely redundant, we definitely need
the interpreter but can get the VM and (later) current active realm from
there - and also the global object while we still need it, although I'd
like to remove Interpreter::global_object() in the future.

This now matches the bytecode interpreter's execute_impl() functions.
2022-08-23 13:58:30 +01:00
Andreas Kling
fb1900e79c LibJS: Make Interpreter::create() call InitializeHostDefinedRealm()
Instead of having two implementations of this AO, let's just have
Interpreter::create() call the new full version of the AO in Realm.
2022-08-05 12:46:39 +02:00
Linus Groh
9f3f3b0864 LibJS: Remove implicit wrapping/unwrapping of completion records
This is an editorial change in the ECMA-262 spec, with similar changes
in some proposals.

See:
- 7575f74
- df899eb
- 9eb5a12
- c81f527
2022-05-03 01:09:29 +02:00
Linus Groh
7767f9be37 LibJS: Rename some variables from "script body" to "script"
This is an editorial change in the ECMA-262 spec.

See: 38a2584
2022-05-01 22:47:38 +02:00
Linus Groh
24d772af7c LibJS: Move additional notes to spec comments onto their own line
Having all spec comments verbatim on their own line with no additions
made by us will make it easier to automate comparing said comments to
their current spec counterparts.
2022-04-11 21:32:37 +01:00
Idan Horowitz
086969277e Everywhere: Run clang-format 2022-04-01 21:24:45 +01:00
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