Man that’s an eye sore. Really annoying to track something in that dump. However it does confirm that the Proxy
template gets instantiated as Proxy<void>
. How that gets achieved is beyond my reach since it seems to happen somewhere in /Sources/Engine/Framework/Backend/BackendScript.cpp
. A file which I can’t seem to find in the engine source code.
So if you have access to the code from that file, the error is detailed here:
/Users/ifs/work/wks-ifs/hop/Outputs/hop/ios-x86_64-debug-engine-device/Deps/urho3d/ios-x86_64-release-device-nocodesign/Install/include/Urho3D/ThirdParty/AngelScript/wrap16.h:17:5: error:
field has incomplete type ‘void’
T value;
^
/Users/ifs/work/wks-ifs/hop/Sources/Engine/Framework/Backend/BackendScript.cpp:65:34: note: in instantiation
of template class ‘gw::Proxy’ requested here
iResult = pScriptEngine->RegisterObjectMethod( “AuthenticationManager”, "Account@+ CreateAcco…
^
Simply put, in file Urho3D/ThirdParty/AngelScript/wrap16.h
at line 15
there’s a template like:
template <typename T> class Proxy { ....
And at line 17
a member variable is created in that Proxy
class, of whatever type was given via the template T
, like so:
T value;
So now if you take it by logic, if I instantiate Proxy
as Proxy<void>
then the value
member type will be void. And you can’t have a void member variable. Basically the whole thing translates to:
class Proxy {
void value;
};
Which is what makes the compiler to moan.
So if you keep extracting further information from that message, you’ll notice that the instantiation happens in file hop/Sources/Engine/Framework/Backend/BackendScript.cpp
at line 65
Where you attempt to register this function:
iResult = pScriptEngine->RegisterObjectMethod( “AuthenticationManager”, "Account@+ CreateAcco…
Which is nicely trimmed exactly where you’re supposed to see how the API is registered and why does it blow up like that.
Now, I haven’t looked much into how the API is exposed to AngelScript. But the approach taken with Proxy
is common in many script binding utilities. Which is basically used to provide storage and type information for a value extracted from a generic storage with no type information.
The storage part plays a nice role in extracting values in a tuple-like fashion and then forward them to a native function-like object (or a similar fashion).
However, since you can’t have void parameters in functions, I assume the failure happens on the returned value.
Long story short, the dump does show where the error originates from, but since it doesn’t show the actual code involved, none of us are likely to understand the cause of it. Let alone explain why.