There is nothing particular about it. It's just a comment I added for myself to check upon at a later stage.

Let me know if you encounter any difficulties and I'll try to help.

Another tip to make it easier to understand, is to compile a script where the opCall method is called explicitly and then checking the debug output of the bytecode (written to the AS_DEBUG folder). You'll want the bytecode to be identical both when the method is called implicitly and explicitly. Turn off the bytecode optimization when doing this (asEP_OPTIMIZE_BYTECODE) so you'll know what instructions the compiler needs to output before the code goes through the optimization pass.

Regards,
Andreas

In case of an implicit this pointer, i.e. when a class method is called from within another method, the CompileFunctionCall() pushes the this pointer onto the stack after it has determined that it is a class method that is being called. You'll find the following code, early in the CompileFunctionCall()


// The object pointer is located at stack position 0
ctx->bc.InstrSHORT(asBC_PSF, 0);
ctx->type.SetVariable(dt, 0, false);
ctx->type.dataType.MakeReference(true);


When it is not an implicit this pointer, then the object pointer is pushed on the stack in CompileVariableAccess() (look for THIS_TOKEN). In this case the compiler will go through the CompileExpressionPostOp where the . operator (if( op == ttDot )) case will invoke the CompileFunctionCall().

Regards,
Andreas

CompileVariableAccess() is pushing the object pointer on the stack. The code just need to make sure to dereference it if necessary.

Test compiling a script that calls the opCall method explicitly and you'll see what needs to be done.


class Class
{
void opCall() {}
}
void main()
{
Class c;
c(); // This should produce the exact same bytecode as the next line
c.opCall();
}



---

The temp variable for the funcdef is to make sure function object stays valid throughout the function call. Otherwise a script like this might crash:



funcdef void FUNC();
FUNC @func = CompileFunction("void myfunc() { @func = null; }");
void main()
{
func();
}


It's obviously a very stupid example, but since AngelScript is supposed to be sandboxed, even stupid examples must not crash.

---

The first call to CompileVariableAccess() must not return global variables, otherwise those will be found before the class methods of the same name. Let's say you have the following script:


funcdef void FUNC();
FUNC @func;
class Class
{
void func() {}

void method()
{
func(); // <-- func is a class method and a global function pointer, both match, but the class method is seen first
}
}


If the first call to CompileVariableAccess() would find the global variable then Class::method() would call the wrong function.

It looks like there might be a bug here. I need to verify, but it looks like the first call to CompileVariableAccess() currently will find matching global variables. If so I'll have to fix that.

There was indeed a bug, but it turns out that it was different from what I expected. Rather than global variables taking precedence over local class methods incorrectly, the problem is that local class methods take precedence over local variables of the same name.

I'll have to make some changes in CompileFunctionCall() to properly handle this. But don't worry too much about this in your work. It's after all only a problem when the variable happens to have the same name as the class method.

I've fixed this problem in revision 1410. The CompileFunctionCall() has been rearranged to properly handle the visibility of local versus member versus global symbols, and CompileVariableAccess() has a new argument to exclude global variables in searches.