https://bugzilla.novell.com/show_bug.cgi?id=381559
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=381559#c2 --- Comment #2 from Brian Luczkiewicz <[EMAIL PROTECTED]> 2008-04-18 19:25:22 MST --- There are actually two problems here.. IL_0019: ldloc.0 IL_001a: dup IL_001b: ldc.i4.5 IL_001c: newarr [mscorlib]System.Object IL_0021: dup IL_0022: ldc.i4.0 **************** missing object load here! **************** IL_0023: ldfld string Fail/'<>c__CompilerGenerated0'::'<1:a>' In addition to the 'missing object load here', there is an "extra" reference to the closure state sitting on the stack from the dup at IL_001a that never gets used (just adding ldloc causes a different IL failure on the ret from the method as a result of this). This only gets generated when Variable.HasInstance is true (which seems only true for generated closure variables when prepare_for_load is true in EmitAssign). The purpose of prepare_for_load is to protect against double-evaluation of the lhs of the assignment, but double-evaluation is not harmful for closure state since they are simple locals references and have no side effects. The dup breaks the auto-generation of arrays for StringConcat nodes when # nodes > 3 (due to matching the params object[] overload of String.Concat). It does no harm when the next operation is a ldfld (e.g. for the simple String.Concat cases where no array is generated). This solution is probably not totally ideal since it always does ldloc twice on the closure state object in compound assignments even when dup could have been used with no troubles. -- 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
