Repository navigation
Give a catch copy thunk a debug scope of its own - #361
Merged
Merged
Conversation
With --di, the `.eh.copy.box.*` thunk a class throw needs was built at the
throw statement's location, which carries that statement's debug scope.
Inside a braced block that scope is a lexical block of the enclosing
function, so the thunk ended up with a subprogram of its own while its
instructions still pointed into the other function, and LLVM rejected the
module ("!dbg attachment points at wrong subprogram for function").
The DefaultLib debug build (`--di`, no `--opt`) throws RangeError inside
blocks, so it stopped emitting: the v0.0-pre-alpha85 release failed on all
four platforms. The suite runs with --di too, but none of its throws sat in
a braced block.
The thunk now takes the same steps a function declaration does: a
subprogram for itself, and a body located under it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This was referenced Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the
v0.0-pre-alpha85release build, which failed on all four platforms (run 36038070141).What broke
With
--di, the.eh.copy.box.*copy thunk a classthrowneeds was built at the throw statement's location, and that location carries the statement's debug scope. When thethrowis inside a braced block, the scope is a lexical block of the enclosing function. The thunk then got a subprogram of its own while its instructions still pointed into the other function, and LLVM rejected the module:DefaultLib's debug build (
--di, no--opt) throwsRangeErrorinside blocks (fetch,Array.with), so it stopped emitting:LNK1181: cannot open input file '.\lib\debug\gc\lib.obj'cannot find -lTypeScriptDefaultLibCore, then debug/compile 0/155Every release variant passed. PR CI is Release-only, and although the suite runs with
--di, none of its throws sat in a braced block, so nothing caught this before the tag. When the throw is not in a block, the thunk silently took the enclosing function's subprogram. That was wrong too, but the verifier accepted it.Fix
mlirGenCatchCopyThunknow does what a function declaration does (MLIRGenFunctions.cpp): it opens a debug scope, creates a subprogram for the thunk, and locates the body under it using the statement's plain location.Tests
00throw_in_block_debug_info.ts(compile + jit; the runner already passes--di --opt_level=0). It fails onmainwith the exact CI error and passes with the fix.Not in this PR
Compiling a file that throws with
--di --optstill fails, with a different error ("inlinable function call in a function with a DISubprogram location must have a debug location"). This existed before this change and doesn't affect the release, since the debug default lib is built without--opt.After merge, the release needs a new tag:
v0.0-pre-alpha85points at5671e4c4and no release object was created from it.🤖 Generated with Claude Code