3 commits

Author	SHA1	Message	Date
Linus Groh	cbbf4abb0d	LibJS: Add a way to get from a GlobalObject to its associated Realm ... 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-10-14 23:02:19 +01:00
Linus Groh	2b8d5696ab	LibJS: Allocate a Realm next to GlobalObject in Interpreter::create() ... Also pass a Realm reference to the Bytecode::Interpreter constructor, just like we pass the GlobalObject.	2021-09-12 11:10:20 +01:00
Linus Groh	d9c3bafcd9	LibJS: Start adding a JS::Realm class (spec's "Realm Record")	2021-09-12 11:10:20 +01:00