[CC1.73][SSP] Tailcall errors

Errors are incorrectly reported on TAILCALL Lua instructions:

local function a()
  -- Call any function that produces an error.
  -- This could be fs.copy("NonExistantFile", "Somewhere") or calling something with the wrong arguments
  error("Um...")
end

a()

This produces a:4:Um… which is the correct line whilst:

local function a()
  -- Returning a function results in a TAILCALL instruction
  return error("Um...")
end

a()

Produces a:6:Um… which is the incorrect line number. I've checked in normal Lua and the expected line numbers occur.

The only solution I can think of is calling .eval() on instances of TailcallVarargs in the LuaClosure though I'm sure there is a better way.

Sorry for all these bug reports.

SquidDev, on 07 March 2015 - 05:22 PM said:

Errors are incorrectly reported on TAILCALL Lua instructions:

local function a()
  -- Call any function that produces an error.
  -- This could be fs.copy("NonExistantFile", "Somewhere") or calling something with the wrong arguments
  error("Um...")
end

a()

This produces a:4:Um… which is the correct line whilst:

local function a()
  -- Returning a function results in a TAILCALL instruction
  return error("Um...")
end

a()

Produces a:6:Um… which is the incorrect line number. I've checked in normal Lua and the expected line numbers occur.

The only solution I can think of is calling .eval() on instances of TailcallVarargs in the LuaClosure though I'm sure there is a better way.

Sorry for all these bug reports.

It appears the latter case returns the error line number as the line the return would return to. So I'm not really seeing the problem here? What is the behavior you expect/desire? And why would you "return error()" in any case? Is this a reduction of some real-world case I'm missing?

Also, this is a luaj issue, not something introduced by CC itself, and so unlikely to be fixed on this end.

:edit: Just checked and I'm not convinced this is even an issue with luaj; codepad has debug output, with the stacktrace, on errors, but even so, that stacktrace seems to exclude middle functions when errors are generated from inside tail calls, reporting only that there was a tail call between without actually identifying it.

With every LuaJ bug, I become more and more convinced that CC should have a custom fork of LuaJ to fix several issues.

ElvishJerricco, on 07 March 2015 - 07:28 PM said:

With every LuaJ bug, I become more and more convinced that CC should have a custom fork of LuaJ to fix several issues.

No, really, I'm pretty sure this is not a luaj bug. It's just how tailcalls work with respect to the stack.

GopherAtl, on 07 March 2015 - 07:42 PM said:

ElvishJerricco, on 07 March 2015 - 07:28 PM said:

With every LuaJ bug, I become more and more convinced that CC should have a custom fork of LuaJ to fix several issues.

No, really, I'm pretty sure this is not a luaj bug. It's just how tailcalls work with respect to the stack.

Nope. You're right that the stack just switches to the tailcalled function instead of going deeper. But that doesn't mean that errors should be reported on the wrong line.

EDIT: Example:

function a(b )
	return string.char(b )
end

a(300)

string.char will error, because 300 isn't valid. But the error will be reported at the a(300) line instead of the string.char(b ) line. Since the error was thrown from string.char, that's the line we should get an error from. Your reasoning for why it's doing the wrong thing is correct, but that doesn't mean the wrong thing is correct.

GopherAtl, on 07 March 2015 - 07:17 PM said:

:edit: Just checked and I'm not convinced this is even an issue with luaj; codepad has debug output, with the stacktrace, on errors, but even so, that stacktrace seems to exclude middle functions when errors are generated from inside tail calls, reporting only that there was a tail call between without actually identifying it.

Well, CodePad produces

line 3: Um...
stack traceback:
    [C]: in function 'error'
    t.lua:3: in function 'a'
    t.lua:6: in main chunk
    [C]: ?

which is what I would expect. Wrapping it in an xpcall then running debug.traceback gives similar results. However in LuaJ the call stack is not preserved. Maybe I'm misunderstanding what you are saying? I actually came across this with one of the fs functions so there are some real world occurrences of this.

:sigh: Fine, ok, you're all correct. I am frankly flabbergasted that this seems like a significant issue to either of you, particularly an issue significant enough to justify forking a massive project so it can be fixed.

GopherAtl, on 07 March 2015 - 08:55 PM said:

:sigh: Fine, ok, you're all correct. I am frankly flabbergasted that this seems like a significant issue to either of you, particularly an issue significant enough to justify forking a massive project so it can be fixed.

It's the pile of LuaJ bugs that this is a part of that makes me suggest that. It's not a huge deal, but it is yet another minor disappointment in the way CC's Lua behaves.