RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-06-01 10:08:10 +00:00
Code Issues Activity Actions

LibJS: Add a way to get from a GlobalObject to its associated Realm

Browse source 
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).
This commit is contained in:
Linus Groh 2021-10-14 12:04:10 +01:00
parent 2447b27d97
commit cbbf4abb0d
4 changed files with 23 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

5
Userland/Libraries/LibJS/Runtime/GlobalObject.h
View file

@ -23,6 +23,9 @@ public:
Console& console() { return *m_console; }
Realm* associated_realm();
void set_associated_realm(Badge<Realm>, Realm&);
Shape* empty_object_shape() { return m_empty_object_shape; }
Shape* new_object_shape() { return m_new_object_shape; }
@ -88,6 +91,8 @@ private:
NonnullOwnPtr<Console> m_console;
WeakPtr<Realm> m_associated_realm;
Shape* m_empty_object_shape { nullptr };
Shape* m_new_object_shape { nullptr };
Shape* m_new_ordinary_function_prototype_object_shape { nullptr };