Skip to content

Preserve ByRef updates in loop conditions - #1294

Draft
CosmonautJones wants to merge 2 commits into
icsharpcode:masterfrom
CosmonautJones:fix/byref-loop-conditions-1129
Draft

CosmonautJones wants to merge 2 commits into
icsharpcode:masterfrom
CosmonautJones:fix/byref-loop-conditions-1129

Conversation

@CosmonautJones

@CosmonautJones CosmonautJones commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #1129.

Problem

When VB passes an Integer to a ByRef Object parameter, it creates a temporary and copies the changed value back after the call. In loop conditions, the converter can put that temporary before the whole loop and copy-back after it. The condition changes the temporary while the body reads a stale original value: the regression's VB body sees 1,2,3, but the old C# sees 0,0,0.

Solution

Use the existing local-function mechanism whenever a loop-condition call needs an argument temporary. Each actual condition evaluation performs copy-in, call and copy-back together. Copy-in-only inputs, constants and omitted optional arguments also receive fresh temporaries. Handle the separate implicit optional-call path and explicit reduced extension receivers, while retaining native while/do control flow and short-circuit behavior.

The shared helper's parent-ByRef forwarding now uses distinct semantic parameter references. That covers references within receivers/arguments without forwarding named-argument labels or nested lambda parameters.

The part most worth maintainer attention is the repeated-evaluation detection and the helper's capture boundaries. The rule stops at the nearest statement or lambda, so ordinary calls in loop bodies retain their existing treatment. The existing If decision path is preserved.

  • 23 new runtime-equivalence facts compile and execute the original VB and generated C# through the established harness. Coverage includes While, all four tested Do forms, zero iterations, body/final values, side-effect counts, Continue/Exit/Return, property/copy-in-only inputs, optional calls, explicit extension receivers, nested loops/captures and If behavior.

Validation

Tested commit: fe9f07991415005840c0436e4fdde2fdae2a24af, Windows x64, existing .NET SDK 10.0.402.

  • Local validation on 2026-10-25: Release/net10.0 and Release/net8.0 builds had 0 warnings/errors each.
  • Actual runtime 10.0.13: 76 focused tests passed; broader suite 665 passed, 0 failed, 3 existing skips.
  • Actual runtime 8.0.32: 76 focused tests passed; broader suite 665 passed, 0 failed, 3 existing skips.
  • The .NET 8 testhost runtime was verified using host traces, diagnostics and a live CoreCLR module path. Its VSTest 18.7.0 launcher used runtime 10.0.13. The repository's .NET 8 reference assemblies were used by the compiler harness in both runs.
  • Broader coverage: both directions' expression tests, C# statement and constructor tests, VB-to-C# self-verifying tests, and newline tests. Existing skips: deeply nested binary expression (too slow), LinqAggregateSumAsync and LinqGroupJoinAsync (VB -> C#: Query Expression Syntax not fully implemented #29).
  • A separate internal AI QA agent challenged the implementation, reviewed the exact final commit, and independently rebuilt/reran the 76-test net10.0 focused suite.
  • Before submission on 2026-10-26, upstream master remained unchanged and the same commit rebuilt and passed the 76-test net10.0 focused suite again (0 failures/skips, 10 seconds). Upstream workflow Build CodeConverter is awaiting maintainer approval for this fork contribution; no jobs have executed yet.

Build commands used dotnet build Tests/Tests.csproj -c Release -f net10.0 and -f net8.0, with --no-restore --disable-build-servers -m:1 -p:UseSharedCompilation=false. The net10.0 runs used dotnet test --no-build --no-restore with bounded filters; net8.0 ran the built assembly through VSTest with /Framework:.NETCoreApp,Version=v8.0 and an explicit installed net8 host. This is not a claim that SDK-8 builds, full upstream CI, other platforms, VSIX/web or the full repository suite passed.

Known existing conversion limits remain explicit: generated helpers that capture structure instance members (CS1673), bare ByRef extension calls on properties without parentheses (CS0206, also reproduced under If), and exploratory ByRef-lambda syntax requiring a preview feature under the harness (CS8652). These failed probes are not counted as passing tests or repaired by this patch.

Process

  • Attachment level: low; open to maintainer-preferred simplification.
  • LLM primarily used: OpenAI Codex (GPT-6), with separate research and QA agents. The implementation, tests and this explanation are AI-written. Travis approved submission of this reviewed patch as a draft PR.
  • Development prompt excerpts (before later approval to submit):
Research VB ByRef copy-back semantics for loop condition evaluation, reproduce the bug, and implement only if still present. Cover While, Do While/Until including bottom-tested forms, side-effect counts, values seen in body, zero iterations, final values, and existing If behavior.

Use bounded runtime-equivalence tests, not snapshot-only evidence. Existing .NET8/10 environments only, no new installs or spending. Separate final QA must challenge hoisting/local-function/control-flow interactions and review the exact final commit after fixes. No public comment, push or PR yet; return review packet and verified limits.

var path = Path.Combine(TestConstants.GetTestDataDirectory(), "SelfVerifyingTests/VBToCS/ByRefLoopConditionTests.vb");
return SelfVerifyingTestFactory.GetSelfVerifyingFacts<VisualBasicCompiler, CSharpCompiler, VBToCSConversion>(path)
.Select(test => new object[] { test });
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth double checking if this is the existing pattern, I had a feeling they were auto detected by

return testFiles.SelectMany(SelfVerifyingTestFactory.GetSelfVerifyingFacts<VisualBasicCompiler, CSharpCompiler, VBToCSConversion>)

Feel free to add better signposting if agents are tripping up on it

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

VB -> C#: incorrect handling of ref arguments in loop conditions

2 participants