summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Interpreter.cpp
AgeCommit message (Collapse)Author
2021-05-13LibJS: Ensure function declarations don't leak outside function scopesLinus Groh
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-04-24LibJS: Add VM::on_call_stack_emptied callbackLinus Groh
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-22Everything: Move to SPDX license identifiers in all files.Brian Gianforcaro
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-13LibJS: Replace two more uses of unwind(ScopeType::None) with stop_unwind()Linus Groh
Same thing, but a lot more clear.
2021-04-02LibJS: Add initial support for PromisesLinus Groh
Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-03-21LibJS: Don't track executing AST nodes in a VectorAndreas Kling
Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21LibJS: Move AST node stack from VM to InterpreterAndreas Kling
2021-03-16LibJS: Implement non-value-producing statements properlyLinus Groh
For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16LibJS: Make Interpreter::run() a void functionLinus Groh
With one small exception, this is how we've been using this API already, and it makes sense: a Program is just a ScopeNode with any number of statements, which are executed one by one. There's no explicit return value at the end, only a completion value of the last value-producing statement, which we then access using VM::last_value() if needed (e.g. in the REPL).
2021-03-01LibJS: Keep track of current AST node inside the call stackJean-Baptiste Boric
2021-02-23Everywhere: Rename ASSERT => VERIFYAndreas Kling
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-10LibJS: Remove a whole bunch of unnecessary #includesAndreas Kling
2021-01-12Libraries: Move to Userland/Libraries/Andreas Kling