summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Bytecode
AgeCommit message (Collapse)Author
2021-07-16LibJS: Replace the boolean argument of Object::set with an enum classIdan Horowitz
This is more serenity-esque and also makes pointing out missing exception checks during reviews much easier.
2021-07-11LibJS: Add support for binding patterns in catch clausesAli Mohammad Pur
`try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11LibJS: Implement parsing and evaluation for AssignmentPatternsAli Mohammad Pur
e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-06LibJS: Remove the non-standard put helper and replace it's usagesIdan Horowitz
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-06LibJS: Add define_direct_property and remove the define_property helperIdan Horowitz
This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-05LibJS: Remove unnecessary value_or() from get()Linus Groh
Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04LibJS: Rewrite most of Object for spec compliance :^)Linus Groh
This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04LibJS: Bring ArrayCreate and ArrayConstructor closer to specIdan Horowitz
Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-01LibJS: Try to fix Clang build (NewClass::m_class_expression is unused)Andreas Kling
2021-07-01LibJS: NewClass bytecode instructionJohan Dahlin
This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-07-01LibJS: Drop "Record" suffix from all the *Environment record classesAndreas Kling
"Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-06-29LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N)Idan Horowitz
This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-27LibJS: Stop qualifying AK::FunctionAndreas Kling
Now that JS function objects are JS::FunctionObject, we can stop qualifying AK::Function and just say "Function" everywhere. Nice. :^)
2021-06-27LibJS: Rename ScriptFunction => OrdinaryFunctionObjectAndreas Kling
These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-24Userland: Replace VERIFY(is<T>) with verify_cast<T>Andreas Kling
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-24LibJS: Rename CallFrame => ExecutionContextAndreas Kling
This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-22LibJS: Remove direct argument loading since it was buggyAndreas Kling
The parser doesn't always track lexical scopes correctly, so let's not rely on that for direct argument loading. This reverts the LoadArguments bytecode instruction as well. We can bring these things back when the parser can reliably tell us that a given Identifier is indeed a function argument.
2021-06-22LibJS: Begin implementing GlobalEnvironmentRecordAndreas Kling
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-22LibJS: Split the per-call-frame environment into lexical and variableAndreas Kling
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-21LibJS: Rename VM::current_scope() => current_environment_record()Andreas Kling
And rename some related functions that wrapped this as well.
2021-06-21LibJS: Rename Environment Records so they match the spec :^)Andreas Kling
This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21LibJS: Add bytecode support for regexp literalsMatthew Olsson
2021-06-20LibJS: Let if yield undefined for branches that don't yield a valueGunnar Beutner
According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-19LibJS: Support object rest elements in the bytecode interpreterMatthew Olsson
2021-06-19LibJS: Support array rest elements in the bytecode interpreterMatthew Olsson
2021-06-19LibJS: Implement array destructuring for the bytecode interpreterMatthew Olsson
2021-06-19LibJS: Support object destructuring in the bytecode interpreterMatthew Olsson
2021-06-19LibJS: Add JumpUndefined bytecodeMatthew Olsson
2021-06-19LibJS: Ensure GetBy{Id,Value} never load <empty> into the accumulatorMatthew Olsson
2021-06-19LibJS: Restructure and fully implement BindingPatternsMatthew Olsson
2021-06-16LibJS: Replace Object's create_empty() with create() taking a prototypeLinus Groh
This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-15LibJS: Add a basic pass manager and add some basic passesAli Mohammad Pur
This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-15LibJS: Rename the overridden Instruction methods to foo_implAli Mohammad Pur
These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15LibJS: Make EnterUnwindContext a terminator opAli Mohammad Pur
Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-15LibJS: Make basic block size customizableAli Mohammad Pur
And keep the default 4 KiB for the code generator.
2021-06-14LibJS: Correctly parse yield-from expressionsAli Mohammad Pur
This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14LibJS: Add LoadArgument bytecode instruction for fast argument accessAndreas Kling
This is generated for Identifier nodes that represent a function argument variable. It loads a given argument index from the current call frame into the accumulator.
2021-06-12LibJS: Store and maintain an "execution generation" counterIdan Horowitz
This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12LibJS: Fix all clang-tidy warnings in Bytecode/Op.hAndreas Kling
- Add missing explicit to constructors - Use move() where appropriate
2021-06-12LibJS: Add missing length() method for NewArrayGunnar Beutner
2021-06-11LibJS: Add bytecode generation for simple ObjectExpressionsGal Horowitz
Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11LibJS: Use an enum class instead of 'bool is_generator'Ali Mohammad Pur
This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11LibJS: Implement bytecode generation for switchMarcin Gasperowicz
2021-06-11LibJS: Add bytecode generation for FunctionExpression :^)Andreas Kling
2021-06-11LibJS: Basic bytecode support for computed member expressionsAndreas Kling
Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11LibJS: Implement generator functions (only in bytecode mode)Ali Mohammad Pur
2021-06-11LibJS: Resolve the `this' value in call expression bytecodeAli Mohammad Pur
2021-06-11LibJS: Automatically split linear bytecode into multiple blocksAli Mohammad Pur
...instead of crashing :^)
2021-06-10LibJS: Remove GlobalObject& argument from VM::construct()Andreas Kling
We can just get the global object from the constructor function.
2021-06-10LibJS: Very basic support for "new" construction in bytecode VMAndreas Kling
This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().