[Mono-dev] An issue with nested lamdas

timeslip timeslip at users.sourceforge.net
Wed Jan 12 05:48:43 EST 2011


I'm attempting to port a linq-based compiler from .net to mono. For the most
part everything works well, but I'm getting unexpected
TargetParameterCountException's being thrown when using the languages
equivalent of function pointers. I've reduced my problem down to this
simple test case:

using System;
using System.Linq.Expressions;

namespace DelegateTest {
  static class MainClass {
    public static int DynCall(Delegate func) {
      return (int)func.DynamicInvoke();
    public static void Main () {
      LambdaExpression ex=Expression.Lambda(typeof(Func<int>),
      LambdaExpression ex2=Expression.Lambda(typeof(Func<int>),
        Expression.Call(typeof(MainClass).GetMethod("DynCall"), ex));
      Func<int> func=(Func<int>)ex2.Compile();

On mono 2.8.2 (running on opensuse 11.1) it throws a
TargetParameterCountException on the func.DynamicInvoke(). The same code
prints the '5' I was expecting when run on .net.

Doing a bit of digging, the problem seems to be that the m_target of the
Delegate is null, instead of pointing at the CompilerServices.Closure that
it should be. As a result, the method invocation ends up with one parameter
less than it was expecting. I don't know enough about mono to see why or
where the Closure is getting lost.

Is this a bug/unimplemented feature in mono, or am I trying to do something
unsupported? (And if so, what is the mono-friendly way of doing this?)

View this message in context: http://mono.1490590.n4.nabble.com/An-issue-with-nested-lamdas-tp3213717p3213717.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

More information about the Mono-devel-list mailing list