summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Runtime/Realm.cpp
AgeCommit message (Collapse)Author
2022-02-07LibJS: Reduce header dependency graph in Realm.hAndreas Kling
2022-01-31LibJS: Remove unnecessary GlobalObject pointer from EnvironmentAndreas Kling
As it turns out, we didn't actually need this pointer. :^)
2021-10-14LibJS: Add a way to get from a GlobalObject to its associated RealmLinus Groh
This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-09-12LibJS: Allocate a Realm next to GlobalObject in Interpreter::create()Linus Groh
Also pass a Realm reference to the Bytecode::Interpreter constructor, just like we pass the GlobalObject.
2021-09-12LibJS: Start adding a JS::Realm class (spec's "Realm Record")Linus Groh