[PATCH v8 1/3] jscript: Lookup and ref the named item's dispatch first, during interpretion.
gabrielopcode at gmail.com
Thu Mar 12 08:29:15 CDT 2020
On 12/03/2020 13:02, Jacek Caban wrote:
> Hi Gabriel,
> On 11/03/2020 14:06, Gabriel Ivăncescu wrote:
>> @@ -2995,6 +3008,8 @@ HRESULT exec_source(script_ctx_t *ctx, DWORD
>> flags, bytecode_t *bytecode, functi
>> hres = create_named_item_script_obj(ctx,
>> if(FAILED(hres)) return hres;
>> + if(variable_obj == ctx->global)
>> + variable_obj = bytecode->named_item->script_obj;
> This could be a separated patch. If in this case caller can't handle
> variable_obj in many cases, maybe it shouldn't handle it at all. It
> seems to me that we could get rid of that argument. exec_source has all
> information needed to handle it by itself.
I can split it of course, but I have some doubts when it comes to
removing it. What should we do in function.c's InterpretedFunction_call?
A possible solution I came up with would be to add a new exec_flag, say
EXEC_NEW_VARIABLE_OBJ and use it in InterpretedFunction_call -- then
create it in exec_source if the flag is set.
In rest of cases, we take the frame->variable_obj if a frame is
available, otherwise the ctx->global or named item's dispatch. All of
this in exec_source of course, then we get rid of the parameter altogether.
Does that sound like a good approach?
More information about the wine-devel