I see. Having a “source” field that refers directly to the script would indeed be unstable. I’m still uncertain about the usefulness of inaccurate frames, though. Wouldn’t the first thing I’d do when I see a trace be to open up the referred script and go to the referred line?
Anyway, my purpose for parsing is not to make decisions based on the content of a frame, but to decide how to display the content. At the very least, it would be useful to have finer control which frames are produced. The level argument of debug.traceback lets you chop off the top, but it would be nice to also chop off the bottom, or just have frames in a list.
Roblox Lua already doesn’t do that since 2013 or so - don’t quite remember when we removed it but we did. The primary motivation for this was to make stack traces easier to understand and debugging easier to use; the secondary motivation was a new feature that would require stack tracing that tail calls would prevent; the feature never happened though.
In general tail calls aren’t super interesting to us, and calls are really fast in the new VM, but it’s possible that at some point in the future we’ll decide that we actually want to emit tail calls in some cases for performance in optimized builds.
This is cool and all… but I kind of need to read the traceback for my unit tester.
I’m using string patterns on the traceback obtained from an xpcall, since I don’t know of any other way to get the error. If the format changes, I’ll just have to change the unit tester’s code. I don’t know how else I would do it.
If you need to do it, you need to do it. Just be aware that the format can change and don’t rely on this as part of code that’s critical for your game to function.