Hvala za teste!

Jaz sem moral err17.p26 spremeniti v:
<pre>typ arrrrrrrray = [300]arrrrrrrray // inf size
var a : arrrrrrrray
fun main():int=300</pre>
Namreč pri meni se sizeof kliče samo na spremenljivkah, ne pa ob konstrukciji tipov, zato je zame typ array = [300]array še veljavna koda, dokler tega tipa ne uporabimo. Najbrž je oboje ok, ne? Specifikacija itak nič ne reče o cikličnih tipih.
Podobno pri err1.p26, err2.p26, err3.p26, err48.p26, err49.p26 sem moral dodati spremenljivko spornega tipa.

Poleg tega se mi test err6.p26 in err7.p26 uspešno prevedeta, čeprav vsebujeta številko, ki ni v veljavnem obsegu za int. Jaz namreč evaluacije const izrazov še nisem implementiral (če se prav spomnim, tega od nas še ni zahtevala nobena domača naloga). Zato tudi dopuščam neveljavne konstante. Namreč gledaje samo atomExpr pri meni ni očitno, ali je dobesedna številka veljavna (lahko je ta številka ravno 2**63 in je pred njo unary -).

test18.p26, test20.p26, test21.p26, test25.p26: tu sem našel grozen lapsus (pozabil return true) v svojem prevajalniku: function tipe in struct tipe in union tipe je vedno štel kot strukturno neekvivalentne. precej bizarno, da sem prestal profesorjeve teste s tako implementacijo.

test28.p26: še en grozen lapsus v mojem prevajalniku: pri return tipu funkcije v ast.funtype sem pozabil delat .actualType(), torej ni sprejel namedtypea. tega spet profesor izgleda ni testiral.

test30.p26: v layouter.java nisem klical actualtype, preden sem castal oftype(funexpr) v funtype.