summaryrefslogtreecommitdiff
path: root/Libraries/LibJS
AgeCommit message (Collapse)Author
2020-10-02LibJS: Add Value::is_nullish()Andreas Kling
2020-10-02Everywhere: Fix typosNico Weber
Mostly in comments, but sprintf() now prints "August" instead of "Auguest" so that's something.
2020-10-01LibJS: Fix fatal mistake in HeapBlock::cell_from_possible_pointer()Andreas Kling
When scanning for potential heap pointers during conservative GC, we look for any value that is an address somewhere inside a heap cell. However, we were failing to account for the slack at the end of a block (which occurs whenever the block storage size isn't an exact multiple of the cell size.) Pointers inside the trailing slack were misidentified as pointers into "last_cell+1". Instead of skipping over them, we would treat this garbage data as a live cell and try to mark it. I believe this is the test-js crash that has been terrorizing Travis for a while. :^)
2020-09-29LibJS: Move Console from Interpreter to GlobalObjectAndreas Kling
Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29LibJS: Reduce use of Interpreter in ReferenceAndreas Kling
2020-09-29LibJS: Reduce use of Interpreter in LexicalEnvironmentAndreas Kling
2020-09-28LibJS: Add missing <AK/Function.h> include in JSONObject.cppAndreas Kling
2020-09-27AK: Move trim_whitespace() into StringUtils and add it to StringViewAnotherTest
No behaviour change; also patches use of `String::TrimMode` in LibJS.
2020-09-27LibJS: Stop using Interpreter& in the iterator operations helpersAndreas Kling
2020-09-27LibJS: Remove a whole bunch of includes of <LibJS/Interpreter.h>Andreas Kling
2020-09-27LibJS: Remove a bunch of unnecessary uses of Cell::interpreter()Andreas Kling
We'll want to get rid of all uses of this, to free up the engine from the old assumption that there's always an Interpreter available.
2020-09-27LibJS: Remove js_string(Interpreter&, ...)Andreas Kling
2020-09-27LibJS: Remove js_bigint(Interpreter&, ...)Andreas Kling
2020-09-27LibJS: Don't require Interpreter& for constructing an AccessorAndreas Kling
2020-09-27LibJS: Reduce Interpreter& usage in the Object classAndreas Kling
2020-09-27LibJS: Don't require Interpreter& in PropertyName and StringOrSymbolAndreas Kling
2020-09-27LibJS: Make all the JS::Value binary op helpers take GlobalObject&Andreas Kling
We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27LibJS: Remove unused js_symbol(Interpreter&, ...)Andreas Kling
2020-09-27LibJS: Remove use of Interpreter& in JSONObject codeAndreas Kling
2020-09-27LibJS: Remove Interpreter& argument to Function::construct()Andreas Kling
This is no longer needed, we can get everything we need from the VM.
2020-09-27LibJS: Make native function/property callbacks take VM, not InterpreterAndreas Kling
More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27LibJS: Make Function::call() not require an Interpreter&Andreas Kling
This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27LibJS: Move scope stack from VM back to InterpreterAndreas Kling
Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27LibJS: Move most of Interpreter into VMAndreas Kling
This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-26LibJS: Remove two unused Interpreter member functionsAndreas Kling
2020-09-25LibJS+LibGUI+js: Handle UnterminatedRegexLiteral in syntax highlightersLinus Groh
2020-09-25Meta+LibHTTP through LibWeb: Make clang-format-10 cleanBen Wiederhake
2020-09-22LibJS: Let the VM cache an empty ("") PrimitiveStringAndreas Kling
Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22LibJS: Move well-known symbols to the VMAndreas Kling
No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22LibJS: Use VM::exception() instead of Interpreter::exception() a bunchAndreas Kling
There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-22LibJS: Add a way to get from a Cell to the VMAndreas Kling
2020-09-22LibJS: Move the current exception from Interpreter to VMAndreas Kling
This will allow us to throw exceptions even when there is no active interpreter in the VM.
2020-09-21LibJS: VM::interpreter() should just assert when no active interpreterAndreas Kling
I accidentally committed some code here to force a crash, but this should just assert.
2020-09-21LibJS: Assert if garbage collection is restarted while ongoingAndreas Kling
We can't GC while we're already in GC. Assert if this happens.
2020-09-21LibJS: Rename InterpreterScope => InterpreterExecutionScopeAndreas Kling
To make it a little clearer what this is for. (This is an RAII helper class for adding and removing an Interpreter to a VM's list of the currently active (executing code) Interpreters.)
2020-09-21LibJS: GC should gather roots from all active interpretersAndreas Kling
If we are in a nested execution context, we shouldn't only mark things used by the active interpreter.
2020-09-20LibJS+Clients: Add JS::VM object, separate Heap from InterpreterAndreas Kling
Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20LibJS: Remove some unnecessary indirection in Object constructorsAndreas Kling
2020-09-20LibJS: Make Interpreter::in_strict_mode() work outside of scopeAndreas Kling
This one is a little weird. I don't know why it's okay for this function to assume that there is a current scope on the scope stack when it can be called during global object initialization etc. For now, just make it say "we are in strict mode" when there is no currently active scope.
2020-09-20LibJS: Don't allocate property table during GC marking phaseAndreas Kling
Shape was allocating property tables inside visit_children(), which could cause garbage collection to happen. It's not very good to start a new garbage collection while you are in the middle of one already.
2020-09-20LibJS: Remove unused argument in NativeFunction constructorAndreas Kling
2020-09-19LibJS: Handle getter exception in JSONObject::serialize_json_property()Linus Groh
In the case of an exception in a property getter function we would not return early, and a subsequent attempt to call the replacer function would crash the interpreter due to call_internal() asserting. Fixes #3548.
2020-09-19LibJS: Do not revisit already visited values in update_function_name()AnotherTest
Fixes #3471, adds a test.
2020-09-18LibJS: Simplify toEval() implementationLinus Groh
2020-09-18LibJS: Add FIXMEs for parsing increment operators with function LHS/RHSLinus Groh
The parser considers it a syntax error at the moment, other engines throw a ReferenceError during runtime for ++foo(), --foo(), foo()++ and foo()--, so I assume the spec defines this.
2020-09-18LibJS: Mark more ASTNode classes as `final`Linus Groh
2020-09-12LibJS: Check validity of computed_property_name() result before using itLinus Groh
This fixes two cases obj[expr] and obj[expr]() (MemberExpression and CallExpression respectively) when expr throws an exception and results in an empty value, causing a crash by passing the invalid PropertyName created by computed_property_name() to Object::get() without checking it first. Fixes #3459.
2020-09-12LibJS: Stop unwinding and reset exception for TryStatement finalizerLinus Groh
This fixes two issues with running a TryStatement finalizer: - Temporarily store and clear the exception, if any, so we can run the finalizer block statement without it getting in our way, which could have unexpected side effects otherwise (and will likely return early somewhere). - Stop unwinding so more than one child node of the finalizer BlockStatement is executed if an exception has been thrown previously (which would have called unwind(ScopeType::Try)). Re-throwing as described above ensures we still unwind after the finalizer, if necessary. Also add some tests specifically for try/catch/finally blocks, we didn't have any!
2020-09-12LibJS: Extract most of Interpreter's run() into execute_statement()Linus Groh
Interpreter::run() was so far being used both as the "public API entry point" for running a JS::Program as well as internally to execute JS::Statement|s of all kinds - this is now more distinctly separated. A program as returned by the parser is still going through run(), which is responsible for creating the initial global call frame, but all other statements are executed via execute_statement() directly. Fixes #3437, a regression introduced by adding ASSERT(!exception()) to run() without considering the effects that would have on internal usage.
2020-09-12LibJS: Fix start position of multi-line tokensBen Wiederhake
This broke in case of unterminated regular expressions, causing goofy location numbers, and 'source_location_hint' to eat up all memory: Unexpected token UnterminatedRegexLiteral. Expected statement (line: 2, column: 4294967292)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 11:36:03 +0000