Fix nested exception handler reachability in ILLink#131236
Conversation
Rescan exception handlers until no newly reachable handler bodies expose additional nested protected regions. Add an async nested-finally regression test for the trimming failure. Assisted-by: GitHub Copilot:gpt-5.6-sol Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2cee0e07-8e06-4275-b1de-508fe931bf95
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Tagging subscribers to this area: @agocke, @dotnet/illink |
There was a problem hiding this comment.
Pull request overview
This PR fixes ILLink’s unreachable-block analysis for exception handlers by repeatedly discovering newly reachable handler bodies until reaching a fixed point, preventing nested handlers (e.g., nested finally blocks in async state machines) from being misclassified as unreachable and incorrectly removed.
Changes:
- Update
UnreachableBlocksOptimizerreachability analysis to iteratively enqueue newly reachable exception handler (and filter) blocks until no additional handlers become reachable. - Add a regression test case exercising an async method with nested
finallyblocks underipconstprop. - Add a dependency library used by the new test to reproduce the nested-handler shape.
Show a summary per file
| File | Description |
|---|---|
| src/tools/illink/src/linker/Linker.Steps/UnreachableBlocksOptimizer.cs | Reworks exception-handler reachability to rescan handlers and traverse newly reachable handler bodies, enabling correct discovery of nested protected regions. |
| src/tools/illink/test/Mono.Linker.Tests.Cases/UnreachableBlock/NestedFinallyInAsyncMethod.cs | New test driver enabling ipconstprop and asserting nested-cleanup executes (via a counter). |
| src/tools/illink/test/Mono.Linker.Tests.Cases/UnreachableBlock/Dependencies/NestedFinallyInAsyncMethod_Lib.cs | New dependency library containing an async method with nested finally blocks to reproduce the scenario. |
Copilot's findings
- Files reviewed: 3/3 changed files
- Comments generated: 0
jtschuster
left a comment
There was a problem hiding this comment.
Source changes look good to me, just wanted some clarifications on why tests are the way they are.
Replace the async dependency-based repro with a synchronous nested-finally case that exercises the same handler reachability bug. Track the test as an expected ILTrim limitation because ILTrim does not implement ipconstprop. Assisted-by: GitHub Copilot:gpt-5.6-sol Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2cee0e07-8e06-4275-b1de-508fe931bf95
There was a problem hiding this comment.
Copilot's findings
Comments suppressed due to low confidence (1)
src/tools/illink/test/Mono.Linker.Tests.Cases/UnreachableBlock/NestedFinallyInFinallyHandler.cs:52
- After removing
CleanupCount,Cleanupshould no longer reference it. KeepingCleanupas a no-op still allows the test to validate that the nested finally body remains reachable (via the existing[Kept]expectation onCleanup).
static void Cleanup() => CleanupCount++;
- Files reviewed: 3/3 changed files
- Comments generated: 2
| [Kept] | ||
| static int CleanupCount; | ||
|
|
||
| public static void Main() | ||
| { | ||
| Test(); | ||
|
|
||
| if (CleanupCount != 1) | ||
| throw new InvalidOperationException(); | ||
| } |
| UnreachableBlock.MultiStageRemoval | ||
| UnreachableBlock.NestedFinallyInFinallyHandler | ||
| UnreachableBlock.ReplacedJumpTarget |
| { | ||
| Reached(); | ||
| } | ||
| finally |
There was a problem hiding this comment.
Could we add one more nested finally here? With only 2 levels, an impl that just scans twice would still pass, so this does not fully test the fixed point loop.
| // Newly reachable handlers can contain protected regions for nested handlers. | ||
| var instrs = Instructions; | ||
| foreach (var handler in ExceptionHandlers) | ||
| for (int handlerIndex = 0; handlerIndex < ExceptionHandlers.Count; handlerIndex++) |
There was a problem hiding this comment.
Should we cache the try ranges before the loop? IndexOf is linear and now runs for every handler on each pass. Probably minor, but easy to avoid.
Fix exception-handler reachability analysis in the unreachable blocks optimizer by rescanning handlers until no newly reachable handler bodies expose additional nested protected regions.
Previously, handlers were scanned only once. A nested handler could therefore be classified as unreachable before its enclosing handler body was traversed, causing required cleanup code to be removed.
Add a regression test covering an async method with nested
finallyblocks.Validation:
UnreachableBlocktests: 22 passedipconstpropenabled and disabledFixes #131088
Note
This content was created with assistance from AI (GitHub Copilot).