Chris, thanks for the report. As a general rule we prefer Obj[] to List so I haven't seen that. Although semantically they are the same thing and since they do take different code paths in the compiler, I've tried to be diligent about adding test cases when List is used. Guess I missed one (or many) case(s) - so I'll take a look.
brianThu 28 Aug 2008
Fixed for next build.
change is to compiler::ResolveExpr line 127:
// expr type must be resolved at this point
if (expr.ctype == null)
throw err("Expr type not resolved: ${expr.id}: ${expr}", expr.location)
// if we resolved to a generic parameter like V or K,
// then use its real underlying type
if (expr.ctype.isGenericParameter)
expr.ctype = expr.ctype.raw
return expr
cgrinds Wed 27 Aug 2008
I'm surprised this:
class CompilerBugEquals { static Void main() { list := ["abc", 4] CompilerBugEquals().works(list) CompilerBugEquals().doesNot(list) } Void works(Obj obj) { tuple := obj as Obj[] echo(tuple[0] == "abc") } Void doesNot(Obj obj) { tuple := obj as List echo(tuple[0] == "abc") //this doesnt } }results in:
brian Wed 27 Aug 2008
Chris, thanks for the report. As a general rule we prefer
Obj[]toListso I haven't seen that. Although semantically they are the same thing and since they do take different code paths in the compiler, I've tried to be diligent about adding test cases whenListis used. Guess I missed one (or many) case(s) - so I'll take a look.brian Thu 28 Aug 2008
Fixed for next build.
change is to compiler::ResolveExpr line 127:
// expr type must be resolved at this point if (expr.ctype == null) throw err("Expr type not resolved: ${expr.id}: ${expr}", expr.location) // if we resolved to a generic parameter like V or K, // then use its real underlying type if (expr.ctype.isGenericParameter) expr.ctype = expr.ctype.raw return exprcgrinds Thu 28 Aug 2008
Thanks Brian, that fixes it.