[Copilot]

LightExpression invocation targets can now be constants containing System.Linq.Expressions.LambdaExpression values. The compiler compiles and invokes these targets through its existing lambda paths.

• Changes

  • Infer the invocation return type from a constant System lambda.
  • Convert the target for compilation, reusing the converted lambda when inlining is disabled.
  • Cover zero- and one-argument invocations.

• Example

  var target = System.Linq.Expressions.Expression.Lambda<Func<int>>(
      System.Linq.Expressions.Expression.Constant(42));
  
  var lightLambda = FastExpressionCompiler.LightExpression.Expression.Lambda<Func<int>>(
      FastExpressionCompiler.LightExpression.Expression.Invoke(
          FastExpressionCompiler.LightExpression.Expression.Constant(target)));
  
  var result = lightLambda.CompileFast()();

• Fixes Support System Lambda as the LightExpression Invocation target #566

[dadhi]

@copilot the idea is not to inline such system expression, instead just compile fast them, without cost of conversion into LightExpression+conversion... But just in case, please check #558 starting from the Expression.cs changes which also uses/implements this feature. Summarize what and how 558 use this feature for.

[Copilot]

@copilot the idea is not to inline such system expression, instead just compile fast them, without cost of conversion into LightExpression+conversion... But just in case, please check https://github....

PR #558’s Expression.cs change infers the invoke return type from an Expression<TDelegate> by finding its Compile() return delegate type. The compiler then recognizes expression-tree-valued invocation receivers, collects the receiver and arguments, and emits receiver.Compile() followed by delegate Invoke(), spilling operands when needed to preserve evaluation order. It avoids converting the outer tree or inlining the runtime expression. Notably, #558 calls System’s Compile(), not FEC’s CompileFast(); its main FEC compilation target is the outer expression. That confirms my prior conversion/inlining approach is not the intended design. The LightExpression compiler currently has no CompileFast(System.Linq.Expressions.LambdaExpression) API, so directly applying the requested nested CompileFast path needs a deliberate bridge to the standard FEC compiler.