summaryrefslogtreecommitdiff
path: root/Libraries/LibJS/Runtime/FunctionConstructor.cpp
AgeCommit message (Collapse)Author
2021-01-12Libraries: Move to Userland/Libraries/Andreas Kling
2020-10-29LibJS: Tweak generated source in 'new Function()' to match ES 2015 specLinus Groh
ES 5(.1) described parsing of the function body string as: https://www.ecma-international.org/ecma-262/5.1/#sec-15.3.2.1 7. If P is not parsable as a FormalParameterList[opt] then throw a SyntaxError exception. 8. If body is not parsable as FunctionBody then throw a SyntaxError exception. We implemented it as building the source string of a complete function and feeding that to the parser, with the same outcome. ES 2015+ does exactly that, but with newlines at certain positions: https://tc39.es/ecma262/#sec-createdynamicfunction 16. Let bodyString be the string-concatenation of 0x000A (LINE FEED), ? ToString(bodyArg), and 0x000A (LINE FEED). 17. Let prefix be the prefix associated with kind in Table 49. 18. Let sourceString be the string-concatenation of prefix, " anonymous(", P, 0x000A (LINE FEED), ") {", bodyString, and "}". This patch updates the generated source string to match these requirements. This will make certain edge cases work, e.g. 'new Function("-->")', where the user supplied input must be placed on its own line to be valid syntax.
2020-10-13LibJS: Cache commonly used FlyStrings in the VMAndreas 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-04LibJS: Use String::formatted() in various other placesLinus Groh
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 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-07-23LibJS: 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-01LibJS: Explicitly pass a "Function& new_target" to Function::constructMatthew Olsson
This allows the proxy handler to pass the proper new.target to construct handlers.
2020-06-20LibJS: Object::initialize() overrides must always call base classAndreas Kling
2020-06-20LibJS: Move native objects towards two-pass constructionAndreas 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-08LibJS: Pass GlobalObject& to AST node execute() functionsAndreas Kling
More work towards supporting multiple global objects.
2020-05-27LibJS: Simplify and normalize publicly-exposed Object functionsMatthew 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-15LibJS: Add side-effect-free version of Value::to_string()Andreas Kling
There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15LibJS: Let parser keep track of errorsLinus Groh
Rather than printing them to stderr directly the parser now keeps a Vector<Error>, which allows the "owner" of the parser to consume them individually after parsing. The Error struct has a message, line number, column number and a to_string() helper function to format this information into a meaningful error message. The Function() constructor will now include an error message when throwing a SyntaxError.
2020-05-13LibJS: Make the Function() constructor throw a SyntaxError, not returnLinus Groh
2020-05-02LibJS: Name functions created by "Function" "anonymous"Linus Groh
...as it is supposed to be.
2020-04-28LibJS: Implement correct attributes for (almost) all propertiesmattco98
Added the ability to include a u8 attributes parameter with all of the various put methods in the Object class. They can be omitted, in which case it defaults to "Writable | Enumerable | Configurable", just like before this commit. All of the attribute values for each property were gathered from SpiderMonkey in the Firefox console. Some properties (e.g. all of the canvas element properties) have undefined property descriptors... not quite sure what that means. Those were left as the default specified above.
2020-04-18LibJS: Move builtin prototypes to the global objectAndreas Kling
This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18LibJS: Pass prototype to Function constructorsAndreas Kling
2020-04-18LibJS: Pass prototype to Error constructorsAndreas Kling
2020-04-13LibJS: Tweak FunctionPrototype::to_string and constructorsStephan Unverwerth
The output of FunctionPrototype::to_string is now more in line with the output in Firefox. The builtin constructors have been extended to include their function name in the output.
2020-04-04LibJS: Add Function() and Function.prototypeLinus Groh