fix debug.traceback failing on anonymous function (#1665)#1666
fix debug.traceback failing on anonymous function (#1665)#1666ChouUn wants to merge 4 commits intoTypeScriptToLua:masterfrom
debug.traceback failing on anonymous function (#1665)#1666Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug in the source map traceback regex pattern to avoid incorrectly matching anonymous function stack entries. The regex is updated to exclude the < character from file path matching, preventing matches against patterns like in function <...> that appear in Lua stack traces.
- Updated regex pattern from
(%S+)to([^%s<]+)to exclude<character - Added comprehensive comments explaining the fix and its limitations
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ypeScriptToLua#1665) Nested IIFEs produce <file.lua:N> notation in debug.traceback(). The old pattern (%S+) captured the "<" prefix, causing sourcemap lookup to fail for anonymous function definition locations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
test/unit/error.spec.ts
Outdated
| })(); | ||
| ` | ||
| .setLuaHeader( | ||
| `__TS__sourcemap = { ["main.lua"] = {["3"] = 7, ["4"] = 8, ["5"] = 9, ["6"] = 8} }\n` + |
There was a problem hiding this comment.
Why are you overriding the source map here? Shouldn't tstl already produce the sourcemap due to the sourcmaptraceback below?
There was a problem hiding this comment.
In our unit test harness we execute Lua via luaL_dostring, so the runtime traceback uses string chunk names ([string "..."]) rather than file-based paths. The traceback looks like:
stack traceback:
[string "local function __TS__ArrayAt(self, relativeIn..."]:2222: in function 'debug.traceback'
(...tail calls...)
[string "..."]:3: in main chunkBecause of this, we don’t get frames like main.lua:5 or anonymous-function locations like <main.lua:4> from real execution, so the regression for #1665 can’t be exercised end-to-end without mocking.
That’s why the test overrides debug.traceback to return a file-based traceback containing <main.lua:N> entries, and also injects a matching __TS__sourcemap keyed by "main.lua" so the sourcemap lookup hits the same file name as the mocked traceback.
test/unit/error.spec.ts
Outdated
| })(); | ||
| ` | ||
| .setLuaHeader( | ||
| `__TS__sourcemap = { ["main.lua"] = {["3"] = 7, ["4"] = 8, ["5"] = 9, ["6"] = 8} }\n` + |
There was a problem hiding this comment.
Both line 4 and 6 map to line 8 here, which seems strange. If you are overriding the default traceback (which I would rather not do unless absolutely necessary), better pick some different numbers so we can assert that both main.lua:4 and \tmain.lua:6: are mapped to the correct values.
There was a problem hiding this comment.
Addressed in d61f863:
- The sourcemap mapping is now copied from the compiler's actual emit rather than hand-crafted, with a sanity check (
getMainLuaCodeChunk) to ensure they stay in sync. - All mapped values are distinct, so regular (
\tmain.ts:4:,\tmain.ts:3:) and anonymous (<main.ts:3>,<main.ts:2>) assertions each verify a unique mapping. - Added explicit
expect(result).toContain("<main.ts:N>")assertions as requested.
…ypeScriptToLua#1665) Use distinct sourcemap values and explicit <main.ts:N> assertions per reviewer request. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
more details in #1665