wren
wren copied to clipboard
Calling a no-parameters function with a parameter
It seems like omitting a parameter in a function definition causes variables in the function body to take parameter values.
var f=Fn.new{
var a=1
System.print(a)
}
f.call(2) // 2
(Not sure if this issue still exists, I'm using Wren in TIC-80 and that may be outdated. Sorry if it's old news.)
This looks like it is still present in 0.2.0
From the docs: It is a runtime error if the number of arguments given is less than the arity of the function. If more arguments are given than the function’s arity they are ignored.
Unfortunately that last part doesn't seem to be true.
Tip: you can try the latest version of Wren in your browser at https://wren.io/try.
What you see is a bug: the arguments are stored in the stack. According to the docs, superfluous arguments should be ignored, by it seems like they're actually passed and overwrite the local variables (which are on the stack too).
This is a known issue and will hopefully be addressed in 0.4.0 in some form.
Is this the same cause as the famous stack corruption issue?
It is, I tested with main branch and it doesn't seems to trigger the
issue anymore. I suspect the stack error can still occurs if a foreign
function triggers a stack resize using wrenEnsureSlots but it should
be less lot visible than the issue seen there.
Note that only one call type has been fixed by the other bug fix. This issue is still present on the other form.
Note also that, whilst this bug still occurs in 0.4.0 if you pass a function to a method:
(1..1).each {
var a
System.print(a) // 1 rather than null
}
thankfully, it doesn't occur with fibers:
Fiber.new {
var a
System.print(a) // null rather than 1
}.call(1)
This is probably because the function passed to the fiber is special in that it can take at most a single argument and you can still call it with an argument even when none is specified in order to give Fiber.yield a return value.
var f = Fiber.new {
var a
System.print(a) // null rather than 1
System.print(Fiber.yield()) // 2
}
f.call(1)
f.call(2)
Fixed with #1124. With a new fresh view, I found it pretty quickly. The ObjFn::arity was not used in wrenCallFunction resulting in approximative ObjFiber::stackTop adjustments. Fixing that exposed an secondary issue where ObjFn::arity was not set for all the ObjFn produced by the compiler. Fixing all these resolved issue and pass all the tests.