Pass JSGlobalObject* to the generated finishCreation functions
Created attachment 285285 [details] Patch
Comment on attachment 285285 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=285285&action=review > Source/WebCore/bindings/scripts/test/TestObj.idl:49 > + EnabledAtRuntime=EnableFeatureName, Did you intend to make this change?
Comment on attachment 285285 [details] Patch Can we make this new argument be a reference instead of a pointer?
I would love to but some callers take a pointer. In general, it's confusing how we pass around both a VM& and a JSGlobalObject* all over, since we normally get the VM from the GO.
(In reply to comment #4) > I would love to but some callers take a pointer. Are you saying that the pointer can be null? Or that we can’t easily add the "*" that would turn those pointers into references? Or something else?
(In reply to comment #5) > (In reply to comment #4) > > I would love to but some callers take a pointer. > > Are you saying that the pointer can be null? Unknown without digging into JSC, and I don't understand whether the VM and JSGO can come from different places. I may need to revise this patch anyway so I'll hold off from checking it in.
Comment on attachment 285285 [details] Patch This may be a silly question but what prevents you from calling globalObject() in finishCreation() instead of passing the globalObject in parameter? It looks like we already do this for RuntimeEnabled features.
> This may be a silly question but what prevents you from calling > globalObject() in finishCreation() instead of passing the globalObject in > parameter? It looks like we already do this for RuntimeEnabled features. Probably nothing prevents you from calling globalObject() -- but if you have the global object already, you save a few loads by passing it instead of calling globalObject().
I don't need this (it was about getting to Settings from bindings, and our generator already supports that).