Fix #3827: keep the while-loop for a ref local used after the loop (avoid an uninitialized hoisted ref decl)#3830
Open
sailro wants to merge 3 commits into
Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a C# decompilation/codegen edge case where a ref local whose declaration is hoisted ahead of a for loop could lose its initializer (ending up as ref T x;), producing invalid C# (CS8174). The change teaches DeclareVariables to detect when the only initialization is the first for-initializer assignment and to move that initializer into the hoisted declaration while removing the for initializer.
Changes:
- Add detection for
for (v = …; …)as the sole initialization when the declaration must be hoisted before theforstatement. - Emit
ref T v = ref …;before the loop and remove the correspondingforinitializer to preserve valid C# for ref locals. - Add a pretty test case covering the “ref local used after loop” scenario (Issue #3827) to ensure round-tripping.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| ICSharpCode.Decompiler/CSharp/Transforms/DeclareVariables.cs | Detects and rewrites the “hoisted ref local + for-initializer assignment” pattern to keep required initializers on ref local declarations. |
| ICSharpCode.Decompiler.Tests/TestCases/Pretty/RefLocalsAndReturns.cs | Adds a regression test case that exercises the fixed pattern and validates the emitted form. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
… of a for-loop A ref local that is used after a for-loop has its declaration hoisted in front of the loop, but its only initialization is the for-initializer ref-assignment. The declaration was then emitted without an initializer (`ref T x;`), which does not compile (CS8174). When a by-ref-like local's matching assignment is the first for-initializer, move the ref-assignment's value up into the declaration (`ref T x = ref expr;`) and drop the for-initializer. Assisted-by: Copilot:claude-opus-4.8:GitHub Copilot CLI
59e4c4a to
e95e77d
Compare
Per @siegfriedpammer: rather than rescue the hoisted for-initializer in DeclareVariables, don't form the for-loop at all. TransformFor now bails when the loop variable is a by-ref-like local used after the loop, leaving the while-loop (matching source); the ref decl keeps its initializer, no CS8174. Reverts the DeclareVariables change; test now expects the while form. Assisted-by: Copilot:claude-opus-4.8:GitHub Copilot CLI
The loop-shape decision can use ILVariable use lists before AST lowering, so avoid creating a for-loop when its iterator updates a byref local that must remain usable after the loop. Assisted-by: OpenAI:openai/gpt-5.5:OpenCode
ad39122 to
819b0ed
Compare
siegfriedpammer
approved these changes
Jul 5, 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 #3827.
A
reflocal used after awhile-loop has its declaration hoisted in front of theloop.
PatternStatementTransformthen rewrote thewhileinto afor, moving thesole ref-assignment into the for-initializer — leaving
ref T x;(no initializer)in front of a headless
for (; cond; x = ref …), which does not compile(CS8174: a by-reference variable must have an initializer).
Fix
Per @siegfriedpammer's review, instead of emitting a headless for-loop,
PatternStatementTransform.TransformFornow leaves the loop as awhilewhen theiteration variable is a by-ref-like local used after the loop. The ref-assignment
stays on the hoisted declaration and the output matches the original source — both
simpler and free of the not-so-nice headless-for form.
Before (does not recompile — CS8174):
After:
Test
Pretty/RefLocalsAndReturns.RefLocalUsedAfterForLoopround-trips the hoisted-decl +while-loop form.
Real-world occurrence: Enums.NET (net461) hash-bucket walk. Same symptom as the
long-closed #1630 (stale-bot closed, no fix); the if/else ref-assignment variant
from #1520 is not addressed here.