void Update()
{
MyEnum enumValue = MyEnumValue;
bool condition = true;
if (condition)
{
if(enumValue is MyEnumValue)
{
int i = 0;
}
}
else
{
int j = 1;
}
}
Results in the following crash while compiling:
> msvcr90d.dll!_wassert(const wchar_t * expr=0x00a54ad8, const wchar_t * filename=0x00a54a20, unsigned int lineno=232) Line 163 C
TestAngelScript.exe!asCByteCode::AddPath(asCArray<cByteInstruction *> & paths={...}, cByteInstruction * instr=0x0034a128, int stackSize=4) Line 232 + 0x20 bytes C++
TestAngelScript.exe!asCByteCode::PostProcess() Line 1642 C++
TestAngelScript.exe!asCByteCode::Finalize() Line 72 C++
TestAngelScript.exe!asCCompiler::FinalizeFunction() Line 237 C++
TestAngelScript.exe!asCCompiler::CompileFunction(asCBuilder * builder=0x00347628, asCScriptCode * script=0x00347740, sExplicitSignature * signature=0x00000000, asCScriptNode * func=0x00346bd8, asCScriptFunction * outFunc=0x003477e0) Line 577 C++
TestAngelScript.exe!asCBuilder::CompileFunctions() Line 637 C++
TestAngelScript.exe!asCBuilder::Build() Line 201 C++
TestAngelScript.exe!asCModule::Build() Line 205 + 0xb bytes C++
Potentially relevant watches at "void asCByteCode::AddPath(asCArray<cByteInstruction *> &paths, cByteInstruction *instr, int stackSize)":
- instr 0x0034a128 {next=0x0034a230 prev=0x00349e10 op=asBC_LABEL ...} cByteInstruction *
+ next 0x0034a230 {next=0x0034a288 prev=0x0034a128 op=asBC_LINE ...} cByteInstruction *
+ prev 0x00349e10 {next=0x0034a128 prev=0x00349f70 op=asBC_Block ...} cByteInstruction *
op asBC_LABEL asEBCInstr
arg 0 unsigned __int64
+ wArg 0x0034a140 short [3]
size 0 int
stackInc 0 int
marked true bool
stackSize 5 int
instr->marked true bool
instr->stackSize 5 int
stackSize 4 int
Now, obviously, this code has been obtained by simplifying actual, useful code .
Strangely, removing the "if/else" will allow the code to compile.
Also, isn't this an illegal use of the identity operator? Someone here found this issue. I'm not the original "author" and I'm thinking whoever wrote this meant to use ==.
In fact, I'm not too sure what the operator should accomplish in this case (aside from logging an error at compile-time).
Note that I'm not 100% sure the issue isn't on my side but, judging by the call stack, I doubt it is.
I'm using v2.23.0.
Any idea?