The old logic for dealing with the parameters within the Unreal function thunk (UPythonGeneratedClass::CallPythonFunction and UPythonCallableForDelegate::CallPythonNative) assumed that Stack.Locals would be set-up correctly for input, and could be written to for output. This isn't true, as Stack.Locals is populated by a memcpy in UObject::ProcessEvent (so isn't safe to write to for non-POD data), and Blueprints just pass along their existing frame data since they skip the call to ProcessScriptFunction (as Python generated functions are marked FUNC_Native).
This change adds a common thunk processing function (PyGenUtil::InvokePythonCallableFromUnrealFunctionThunk) which is used when calling into Python from an Unreal function thunk. This function steps the data off the stack frame for each property, copying input data to Python, and building the output chain (FOutParmRec) from output data addresses. This matches what the UHT generated thunk does for native functions (via P_GET_PROPERTY and P_GET_PROPERTY_REF), as well as what ProcessScriptFunction does for functions with Blueprint bytecode.
#jira UE-75405
#jira UE-75449
[FYI] Rex.Hill
#rb Dan.OConnor
#ROBOMERGE-OWNER: lina.halper
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 7064650 in //UE4/Release-4.23/... via CL 7064651
#ROBOMERGE-BOT: ANIM (Main -> Dev-Anim) (v367-6836689)
[CL 7124296 by jamie dale in Dev-Anim branch]
The old logic for dealing with the parameters within the Unreal function thunk (UPythonGeneratedClass::CallPythonFunction and UPythonCallableForDelegate::CallPythonNative) assumed that Stack.Locals would be set-up correctly for input, and could be written to for output. This isn't true, as Stack.Locals is populated by a memcpy in UObject::ProcessEvent (so isn't safe to write to for non-POD data), and Blueprints just pass along their existing frame data since they skip the call to ProcessScriptFunction (as Python generated functions are marked FUNC_Native).
This change adds a common thunk processing function (PyGenUtil::InvokePythonCallableFromUnrealFunctionThunk) which is used when calling into Python from an Unreal function thunk. This function steps the data off the stack frame for each property, copying input data to Python, and building the output chain (FOutParmRec) from output data addresses. This matches what the UHT generated thunk does for native functions (via P_GET_PROPERTY and P_GET_PROPERTY_REF), as well as what ProcessScriptFunction does for functions with Blueprint bytecode.
#jira UE-75405
#jira UE-75449
[FYI] Rex.Hill
#rb Dan.OConnor
#ROBOMERGE-SOURCE: CL 7064650 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v367-6836689)
[CL 7064651 by jamie dale in Main branch]
Failing to do this leads to a Native instance inside a non-native instance, which causes GC confusion
#jira UE-74616
#rb Lauren.Ridge
#ROBOMERGE-VERSION: 348-6547088
#ROBOMERGE-OWNER: lina.halper
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 6536762 via CL 6538364 via CL 6538485
#ROBOMERGE-BOT: ANIM (Main -> Dev-Anim)
[CL 6564488 by jamie dale in Dev-Anim branch]
We now ARO these pending types to stop them being GC'd, and added unreal.flush_generated_type_reinstancing() to allow you to force the reinstancing to happen at a certain point in your script (rather than when it ends, or on the next Tick).
#jira UE-72853
#rb Chris.Gagnon
#lockdown Cristina.Riveron
#ROBOMERGE-OWNER: lina.halper
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 5956901 in //UE4/Release-4.22/... via CL 5956925
#ROBOMERGE-BOT: ANIM (Main -> Dev-Anim)
[CL 5962663 by jamie dale in Dev-Anim branch]
