[Mono-bugs] [Bug 442129] New: Delay local variable capture until just before anonymous methods

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=442129


           Summary: Delay local variable capture until just before anonymous
                    methods
           Product: Mono: Compilers
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: C#
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: lunchtimemama at gmail.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


Test Case:

void Foo()
{
    int i = 0;

    for (; i < 1000; i++) {
        DoSomethingWithAnInt (i);
    }

    DoSomethingWithADelegate (() => i != 5);
}

Actual Result:

The compiler captures the variable 'i' at the start of the method. This means
that all uses of 'i' in the for loop are done through the instance of the
compiler generated type. Each read requires two IL instructions (ldloc and
ldfld) and each write requires two IL instructions (ldloc and stfld).

Expected Result:

Delay capturing a local variable until just before the first anonymous method
in which it appears. Each use of the variable prior to the anonymous method can
be done directly (reads are a simple ldloc and writes are a simple stloc).
Then, before the anonymous method is used, the variable can be hoisted into the
closure object and all subsequence uses of the variable can be channeled
through that object as per usual. Also, the instantiation of the closure object
could be delayed until just before the first variable is captured rather than
at the start of the method (as is currently done). That way if the method
exists (normally or exceptionally) before the first anonymous method is needed,
an unnecessary object allocation will have been avoided.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.