Hi,

for some of the latest AngelScript versions I've been getting an assert in as_compiler.cpp, function CompileStatementBlock, asASSERT( tempVariables.GetLength() == 0; ) . This still persists in the latest SVN revision.

I seem to be able to trigger it (at least) with the following if statement, where RayQueryResult is a value type, Drawable is a reference type, and String is a value type string adapted from the AngelScript addons.

RayQueryResult res;
if (res.drawable.typename == "AnimatedModel") // compiling this triggers the assert
{
  Print("is animated");
}

If I split up the if statement as follows, it will not assert:

RayQueryResult res;
Drawable@ dr = res.drawable;
if (dr.typename == "AnimatedModel")
{
  Print("is animated");
}

The relevant class and function registrations should be:

engine->RegisterObjectType("String", sizeof(String), asOBJ_VALUE | asOBJ_APP_CLASS_CDAK);
engine->RegisterStringFactory("String", asFUNCTION(StringFactory), asCALL_CDECL);
engine->RegisterObjectMethod("String", "bool opEquals(const String&in) const", asMETHODPR(String, operator ==, (const String&) const, bool), asCALL_THISCALL);
 
engine->RegisterObjectType("Drawable", 0, asOBJ_REF);
engine->RegisterObjectMethod("Drawable", "const String& get_typeName() const", asMETHODPR(Drawable, GetTypeName, () const, const String&), asCALL_THISCALL);
 
engine->RegisterObjectType("RayQueryResult", sizeof(RayQueryResult), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_CLASS_C);
engine->RegisterObjectBehaviour("RayQueryResult", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(ConstructRayQueryResult), asCALL_CDECL_OBJLAST);
engine->RegisterObjectMethod("RayQueryResult", "Drawable@+ get_drawable() const", asFUNCTION(RayQueryResultGetDrawable), asCALL_CDECL_OBJLAST);

Thanks.

This is very likely related to, and possibly the same bug reported here: http://www.gamedev.net/topic/638613-asassert-in-file-as-compillercpp-line-675/

I will look into this as soon as possible. Hopefully I'll have a fix available by the end of the day today.

Thanks! Like in that other thread, I've also configured the engine for allowing unsafe references, in case that makes a difference.

The bugs weren't related after all. In fact the bug you reported isn't specific for unsafe references as it's reproduceable even without allowing unsafe references.

I'm still investigating the cause but it appears to be related to the virtual property accessors, especially the nested access of a virtual property on a virtual property.

I've fixed this bug in revision 1565.

Excellent!