[Validation] Analyzer diagnostics for loop iterators captured in closures

[oroztocil]

Scenario contact: @ilonatommy

Scenario

A for loop that renders a button per item, with each handler referring to the loop counter, compiles cleanly and then does the wrong thing: every button acts on the last item, because the counter is one variable shared by every iteration. This validates that the build points the pattern out before it reaches a user.

Minimum build

.NET 11 Preview 7 or later.

Configurations to cover

• Blazor Web App
  • Static SSR
  • Interactive Server
  • Interactive WebAssembly
  • Interactive Auto
• Standalone WebAssembly
• Hybrid (MAUI)

These diagnostics are produced by the compiler, so they do not vary by render mode. The configuration below is the one needed to reproduce the runtime behavior the warning predicts, not a matrix to work through.

Also exercise

• Published output
• An existing .NET 10 app upgraded to .NET 11
• Trimming or ahead-of-time compilation
• More than one server instance, or a proxy in front
• Hot Reload
• An IDE as well as the command line
• Container

Setup

Id	Title	Code fix
BL0014	For loop iterator used inside a closure	No

What to build

A component with a for loop rendering a list, covering each shape the analyzer is meant to flag:

• A button whose @onclick lambda uses the loop counter.
• A lambda that also takes event args and still uses the counter, @(e => Handle(e, i)).
• An <input @bind="items[i]" />, where the counter is used as an indexer in a two-way binding.
• A child component taking an EventCallback, <MyComponent OnClick="@(() => Handle(i))" />.
• A child component whose ChildContent renders the counter, <MyComponent>Item @i</MyComponent>.

Then the shapes that are correct and must stay quiet:

• The same loop with var index = i; copied inside the body.
• The same list rendered with foreach.
• foreach (var i in Enumerable.Range(0, items.Length)).

Show which item each control acted on, so the wrong behavior is visible rather than inferred.

Things to try

• Building at the command line and in an IDE, and comparing what each reports.
• Running the app and clicking every button in the flagged loop.
• Typing into the @bind inputs and checking which item each one wrote to.
• Copying the counter to a local inside the loop body, then rebuilding and clicking again.
• Rewriting the loop as foreach, then rebuilding.
• Using the counter in the loop body but not inside a closure, to see whether it is flagged.

Expected behavior

The pattern is flagged in every shape where it misbehaves, and the shapes that work are left alone.

Must hold

• All five flagged shapes produce a BL0014 warning naming the iterator variable: the @onclick lambda, the lambda with event args, the @bind indexer, the EventCallback, and the ChildContent.
• Clicking the buttons in the flagged loop reproduces the behavior the message predicts: they act on the final value rather than their own.
• Typing into a flagged @bind input writes to the wrong item, matching what the warning predicts.
• The copied-local loop, the foreach loop, and the foreach over Enumerable.Range produce no warning and behave correctly.
• Using the counter outside a closure produces no warning.
• The warnings appear both at the command line and in the IDE, at the same lines.

Expected differences between configurations

• None. The warning is produced at compile time and is identical in every configuration.

Documentation to use

• ASP.NET Core Blazor event handling

What to report

Report results using the format described in the validation testing manual. Include link to a repository with the test app.

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• Add analyzer to check for closing over loop variable #10476
• [Blazor] Consider an analyzer to suggest using foreach instead of for in Blazor code. #16815
• Improve usability when using uncaptured iteration variables in Blazor bindings #25252

[oroztocil]

@irfanajaffer Just heads-up, I added few more cases to the scenario.

[irfanajaffer]

Test report

• Build tested: 11.0.100-preview.7.26381.103
• Configuration tested: Blazor Web App with Interactive Server rendering
• Also exercised: Visual Studio and command-line builds, Release publish
• OS, browser, IDE: Windows, Microsoft Edge, Visual Studio 2022, PowerShell 5.1
• Sample app: irfanajaffer/BlazorLoopClosureDemo
• Outcome: works as expected

Checks

Check	Result	Evidence
All five required unsafe shapes produce BL0014 and name iterator i	Pass	@onclick, event args, @bind, EventCallback, and ChildContent build output
Buttons in the flagged @onclick loop act on the final iterator value	Pass	All buttons report index 3
A flagged lambda with event args acts on the final iterator value	Pass	All event-args handlers report index 3
Typing into a flagged @bind input writes to the wrong item	Pass	Binding writes to the extra final-index item
The copied-local loop produces no warning and behaves correctly	Pass	Buttons report their own indexes
The foreach loop produces no warning and behaves correctly	Pass	foreach buttons report their own indexes
foreach over Enumerable.Range produces no warning and behaves correctly	Pass	Range buttons report their own indexes
Using the iterator in the loop body outside a closure produces no warning	Pass	Values 0, 1, and 2 render correctly
Warnings appear at the same locations in the IDE and command line	Pass	Visual Studio Error List and command-line output

The command-line rebuild succeeded with 8 BL0014 warnings and 0 errors. The five required unsafe pages each produced the expected warning. The additional nested-loop page produced one warning for i and one for j, and the async-capture page produced one warning for i. No other compiler warnings were reported.

Additional coverage

Case	Expected	Result	Runtime observation
Nested for loops capture both iterators	BL0014 for i and j	Pass	A deferred handler receives the final values for both iterators
Async lambda captures the iterator	BL0014 for i	Pass	Every button reports async index 3
foreach over items.Index()	No BL0014	Pass	Each button reports its own item and index
Select index overload followed by foreach	No BL0014	Pass	Each button reports its own item and index
Method-group event handler	No BL0014	Pass	The handler runs without capturing the iterator
Lambda invoked immediately in the loop body	No BL0014	Pass	Rows render doubled values 0, 2, and 4

Evidence for these cases: nested and async capture, safe indexed iteration, and Release publish output.

Problems

None.

Documentation

The ASP.NET Core Blazor event-handling documentation correctly explains the loop-variable capture behavior and recommends copying the iterator to a local variable or using foreach. It does not currently mention diagnostic ID BL0014.