You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm hitting a this error where the transpiler runs out of temp variables. Specifically, when I use object initializers inside of an array, the objects are created using temp variables. However, they are not released afterwards, so if I do this repeatedly in one function, the transpiler runs out of temp variables, even though I never use more than 17 in one list.
To reproduce:
internalclassBugTest{publicintx;staticvoidBreakStuff(){// First list with just 10 constructorsvarlist1=new BugTest[]{new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},};// First list with 10 morevarlist2=new BugTest[]{new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},new BugTest(){x=1},};}}
It seems like the issue is here where the temp variables are bound to a function, instead of a scope, so you get 17 total for the whole function, even when you could reasonable reuse them. In the example above, for example, the first 10 temp variables go out of scope as soon as the first list is constructed, and they could be reused in the second. However, I don't hit this issue with List constructors (they release each temp variable after adding it to the list, so only 1 temp is used), so I'm guessing you have a workaround already that just needs to be extended to arrays.
Further, I'm not sure there any reason that temp variables have to be limited. Why not generate them dynamically with a prefix, like __temp__1, __temp__2, __temp__3, ... etc.? I suppose someone might happen to use that variable name, but in that case you could give the error, rather than to anyone using more than 17 temp variables.
Another solution for object initializers in particular would be to create a function that takes in an object and a table of key-value pairs and initializes the object to those values, then returns the object. Then you could inline the object initializer, rather than using a temp variable at all, e.g.:
list:Add(__initialize(class(), {'x': 1}))
Thanks as always for your work - this is a great tool!
The text was updated successfully, but these errors were encountered:
I'm hitting a this error where the transpiler runs out of temp variables. Specifically, when I use object initializers inside of an array, the objects are created using temp variables. However, they are not released afterwards, so if I do this repeatedly in one function, the transpiler runs out of temp variables, even though I never use more than 17 in one list.
To reproduce:
It seems like the issue is here where the temp variables are bound to a function, instead of a scope, so you get 17 total for the whole function, even when you could reasonable reuse them. In the example above, for example, the first 10 temp variables go out of scope as soon as the first list is constructed, and they could be reused in the second. However, I don't hit this issue with List constructors (they release each temp variable after adding it to the list, so only 1 temp is used), so I'm guessing you have a workaround already that just needs to be extended to arrays.
Further, I'm not sure there any reason that temp variables have to be limited. Why not generate them dynamically with a prefix, like
__temp__1
,__temp__2
,__temp__3
, ... etc.? I suppose someone might happen to use that variable name, but in that case you could give the error, rather than to anyone using more than 17 temp variables.Another solution for object initializers in particular would be to create a function that takes in an object and a table of key-value pairs and initializes the object to those values, then returns the object. Then you could inline the object initializer, rather than using a temp variable at all, e.g.:
Thanks as always for your work - this is a great tool!
The text was updated successfully, but these errors were encountered: