serenity - The Serenity Operating System 🐞

Age	Commit message (Collapse)	Author
2021-01-12	Libraries: Move to Userland/Libraries/	Andreas Kling

2020-10-13	LibJS: Cache commonly used FlyStrings in the VM	Andreas Kling
	Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-04	LibJS: Use String::formatted() for throw_exception() message	Linus Groh

2020-09-27	LibJS: Remove a whole bunch of includes of <LibJS/Interpreter.h>	Andreas Kling

2020-09-27	LibJS: Remove Interpreter& argument to Function::construct()	Andreas Kling
	This is no longer needed, we can get everything we need from the VM.
2020-09-27	LibJS: Make native function/property callbacks take VM, not Interpreter	Andreas 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-27	LibJS: 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-27	LibJS: Move most of Interpreter into VM	Andreas 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-22	LibJS: Move well-known symbols to the VM	Andreas 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-07-23	LibJS: Simplify Cell::initialize()	Andreas Kling
	Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-11	LibJS: Use macros to enumerate well-known symbols	Matthew Olsson
	Not only is this a much nicer api (can't pass a typo'd string into the get_well_known_symbol function), it is also a bit more performant since there are no hashmap lookups.
2020-07-09	LibJS: Move global symbol map from SymbolObject to Interpreter	Matthew Olsson
	This allows different instances of the Interpreter to have their own global symbols. Also makes Symbol non-copyable and non-moveable.
2020-07-01	LibJS: Explicitly pass a "Function& new_target" to Function::construct	Matthew Olsson
	This allows the proxy handler to pass the proper new.target to construct handlers.
2020-06-29	LibJS: Initial class implementation; allow super expressions in object	Jack Karamanian
	literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when \|this\| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when \|this\| has already been initialized (the super constructor was already called).
2020-06-20	LibJS: Object::initialize() overrides must always call base class	Andreas Kling

2020-06-20	LibJS: Move native objects towards two-pass construction	Andreas Kling
	To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20	LibJS: Pass GlobalObject& to native functions and property accessors	Andreas Kling
	More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-11	LibJS: Consolidate error messages into ErrorTypes.h	Matthew Olsson
	Now, exceptions can be thrown with interpreter.throw_exception<T>(ErrorType:TYPE, "format", "args", "here").
2020-05-27	LibJS: Simplify and normalize publicly-exposed Object functions	Matthew Olsson
	Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-17	LibJS: Add symbol objects	mattco98
	This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.