Tested on rev926 (the latest) and rev838.

The following code causes a crash after a call to asCModule::Build():


class T
{
array<T@> Ts;

T@ Get(uint n)
{
return (n>=Ts.length()) ? null : Ts[n]; // i don't think parentheses should be needed there anyway
}
}


Call stack:

> as.dll!asCArray<asCObjectType *>::GetLength() Line 133 + 0x3 bytes C++
as.dll!asCObjectType::Implements(const asCObjectType * objType=0x0053a388) Line 211 + 0x1d bytes C++
as.dll!asCCompiler::ImplicitConvObjectToObject(asSExprContext * ctx=0x0018ed58, const asCDataType & to={...}, asCScriptNode * node=0x00513128, EImplicitConv convType=asIC_IMPLICIT_CONV, bool generateCode=true, asCArray<int> * reservedVars=0x00000000, bool allowObjectConstruct=true) Line 4425 + 0x1b bytes C++
as.dll!asCCompiler::ImplicitConversion(asSExprContext * ctx=0x0018ed58, const asCDataType & to={...}, asCScriptNode * node=0x00513128, EImplicitConv convType=asIC_IMPLICIT_CONV, bool generateCode=true, asCArray<int> * reservedVars=0x00000000, bool allowObjectConstruct=true) Line 4281 C++
as.dll!asCCompiler::PrepareArgument(asCDataType * paramType=0x0053ae58, asSExprContext * ctx=0x0018ed58, asCScriptNode * node=0x00513128, bool isFunction=false, int refType=0, asCArray<int> * reservedVars=0x00000000, bool __formal=true) Line 1303 C++
as.dll!asCCompiler::CompileReturnStatement(asCScriptNode * rnode=0x004ff258, asCByteCode * bc=0x0018eec4) Line 3164 C++
as.dll!asCCompiler::CompileStatement(asCScriptNode * statement=0x004ff258, bool * hasReturn=0x0018f08f, asCByteCode * bc=0x0018eec4) Line 2155 C++
as.dll!asCCompiler::CompileStatementBlock(asCScriptNode * block=0x003d51f8, bool ownVariableScope=false, bool * hasReturn=0x0018f08f, asCByteCode * bc=0x0018f054) Line 711 C++
as.dll!asCCompiler::CompileFunction(asCBuilder * builder=0x0053a170, asCScriptCode * script=0x0053a240, asCScriptNode * func=0x003d8d98, asCScriptFunction * outFunc=0x0053a558) Line 331 C++
as.dll!asCBuilder::CompileFunctions() Line 544 C++
as.dll!asCBuilder::Build() Line 182 C++
as.dll!asCModule::Build() Line 140 + 0xb bytes C++


This is written to the output before the crash (concerning the 'return' line):

Can't implicitly convert from 'T' to <null handle>.
Both expressions must be of the same type.


Two points of interest:
1. Changing array<T@> to T@[] changes the error, it's 'T@&' instead of 'T'.
2. Placing this code inside a larger one sometimes makes the bug go away, or at least the crashing part.

Edit: coming to think of the errors, I understand this is because the null in the ?: conditional is of unknown type before the comparison is made to ensure both ?: sides return the same type. I am still interested why changing array<T@> to T@[] changes the message, as I thought that the latter is - for now - just a syntactic sugar for the former. Anyway, the crash issue remains.

Edit2: even more simplistic example (getting both errors and crash):

class T
{
T@ Get()
{
T@ r;
return (false ? null : r);
}
}


Thanks for the bug report. I'll look into this.

You actually stumbled across two completely separate bugs.

In the second example you isolated one of them, i.e. the one when a ternary condition operator is compiled with a 'null' as the first expression. The compiler wasn't properly identifying this scenario and implicitly converting it to the type of the second expression. I've fixed this bug in revision 930.

The other bug is still under investigation, but I've identified that it is because your class has the same name as the array template subtype. The bug is causing the compiler to instanciate the wrong type in this case. I'm still working on the fix for this.

I've fixed the other bug in revision 931.

Thanks,
Andreas

Was the second bug responsible for reporting "Can't implicitly convert from 'T@&' to <null handle>" instead of "Can't implicitly convert from 'T' to <null handle>." after changing "array<T>" to "T[]"? I am unsure now if I get it right that these two are syntactically equivalent.

Yes, it was causing that. array and T[] really is the same type, however they are parsed differently, and the bug was how the parsed information was interpreted to determine the actual type.