When a method parameter is a fully closed generic type (ie doesn't depend on a method generic's parameters), we never converted the parsed lambda expression to an actual expression.
Example:
[Test]
public void Lambda_Issue_262()
{
var list = new List<int> { 10, 30, 4 };
var options = InterpreterOptions.Default | InterpreterOptions.LambdaExpressions;
var interpreter = new Interpreter(options);
interpreter.SetVariable("b", new Functions());
interpreter.SetVariable("list", list);
var results = interpreter.Eval<List<int>>(@"b.Add(list, t => t + 10)");
Assert.AreEqual(new List<int> { 20, 40, 14 }, results);
}
public class Functions
{
public List<int> Add(List<int> list, Func<int, int> transform)
{
return list.Select(i => transform(i)).ToList();
}
}
In that case, Func<int, int> is a fully closed generic type, and thus t => t + 10 was never converted to the proper Linq expression.
Note: I also fixed a bug where in b.Add(list, t => t + 10), list, t was improperly seen as the two arguments to the lambda expression.
When a method parameter is a fully closed generic type (ie doesn't depend on a method generic's parameters), we never converted the parsed lambda expression to an actual expression.
Example:
In that case,
Func<int, int>
is a fully closed generic type, and thust => t + 10
was never converted to the proper Linq expression.Note: I also fixed a bug where in
b.Add(list, t => t + 10)
,list, t
was improperly seen as the two arguments to the lambda expression.Fixes #262