Repository navigation
Leave no half-built ts.If behind when a conditionalValue branch fails - #352
Merged
Merged
Conversation
MLIRCodeLogicHelper::conditionalValue returned failure with its IfOp still in the IR - an empty or none-typed region - and the insertion point still inside it. Whenever the caller carried on, the failure turned into bad IR further on: "'ts.If' op expects a non-empty block" in place of the branch's own error (seen as `x instanceof C` of a -shared class before #351). It now erases the IfOp and puts the insertion point back before returning. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Sep 23, 2026
ASDAlexander77
added a commit
that referenced
this pull request
Sep 24, 2026
`f?.(1)` for a callee that needs two arguments failed with TS2554 but left its ts.If in the IR, with a then-block holding no ResultOp and an unfilled else. #352 fixed the same shape in conditionalValue. The if is now erased before the failure is returned. No caller carries on after this failure today: at every site tried (local, module level, class field, template literal, ??, typeof) the compile stops with the TS2554 error alone, on main as well. This keeps it that way for a caller that does. The new call-arity case, optional_call_value, uses the result inside an expression at module level, in a global's initializer. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.
Summary
When a branch failed,
MLIRCodeLogicHelper::conditionalValuereturned failure but left itsIfOpin the IR, with an empty or none-typed region, and left the insertion point inside it. If the caller carried on, the failure turned into bad IR further on. For example,x instanceof Cof a-sharedclass, before #351, gave "'ts.If' op expects a non-empty block" instead of the branch's own error.It now erases the
IfOpand puts the insertion point back before returning failure.Verification
#351 removed the trigger, so no ordinary program reaches this failure path any more, and there's no new regression test. I checked it by temporarily forcing
mlirGenInstanceOfOpaqueto fail for a dynamically imported class:print(a instanceof M.Failure)now stops with that forced error rather than the verifier error.Found but not fixed here
The same forced failure inside the generated
___unbox<C>(the<C>anyValuecast) is still swallowed. The instantiation compiles without the failedif (a instanceof C) return a;, so the cast always throws "Can't cast from any type", and no error is printed. The error is raised in the real pass (not dummy, not partial resolve). The most likely explanation is that a failed generic instantiation leaves its function in the module and a retry reuses it. That's the "dirt" TODO inmlirGenNoScopeVarsAndDisposable: a general MLIRGen issue, outside this PR.Tests
🤖 Generated with Claude Code