FastExpressionCompiler: InvalidOperationException in the Mapster

System.InvalidProgramException: ‘Common Language Runtime detected an invalid program.’

StackTrace

   at Mapster.TypeAdapter.Adapt[TSource,TDestination](TSource source) in D:\Dev\Mapster\src\Mapster\TypeAdapter.cs:line 55
   at Benchmark.TestAdaptHelper.ConfigureMapster(Customer customerInstance, MapsterCompilerType type) in D:\Dev\Mapster\src\Benchmark\TestAdaptHelper.cs:line 114
   at Benchmark.Benchmarks.TestComplexTypes.SetupFec() in D:\Dev\Mapster\src\Benchmark\Benchmarks\TestComplexTypes.cs:line 70
   at Benchmark.Program.Main(String[] args) in D:\Dev\Mapster\src\Benchmark\Program.cs:line 22

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 21 (13 by maintainers)

Commits related to this issue

added failing test for #301 — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
fixing #301 and C# pretty printer — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
#301 added the failing test for compiling the ListInit for the Dictionary — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
fixed the dictionary case for #301; optimize multiple method call emits — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
adding the new test case fot the #301; fixed c# name output of the generics with mutiple type arguments — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
added the simplified test for the Invoke Lambda with return for #301 — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
fixed the inlined lambda invocation for the #301 — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
better fix for the #301 — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
uncomment tests for the #301 — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago
fixed the case for the #301 with the private property — committed to dadhi/FastExpressionCompiler by dadhi 3 years ago

Most upvoted comments

@cojocaru-dragos-alexandru

I have run the tests from the Mapster with the FEC 3.2 and everything is passing:

So it would be hard to impossible to figure out until I have the failing sample/test.

dadhi on Jul 3, 2021

Found the cause of Dictionary tests failing - the V3 has added the support for the ListInit expression (V2 used the fallback) but there is a bug in emitting the ElementInit for the Dictionary. Fixing now.

dadhi on Apr 23, 2021

Hey, good to join. I created fec branch (https://github.com/MapsterMapper/Mapster/tree/fec). I tested unit tests, 10 cases failed. Most seemed to related to dictionary.

Just wondering, for default usage, Should we expect FEC to fallback to original lambda.Compile or not? In most cases, we could enjoy performance boost. In corner cases, app still working.

chaowlert on Apr 22, 2021

I checked earlier today, and the example I provided for LINQPad runs with no exception. 😄

CyberBotX on Apr 21, 2021

I don’t think this problem has been fixed, even up to 3.0.4. I just tried the following short snippet in LINQPad using FastExpressionCompiler 3.0.4 and Mapster 7.1.5:

class Test
{
	public string? TestString { get; set; }
}

void Main()
{
	TypeAdapterConfig.GlobalSettings.Compiler = exp => exp.CompileFast();
	_ = TypeAdapterConfig.GlobalSettings.Default.MapToConstructor(true).PreserveReference(true);
	
	var test1 = new Test()
	{
		TestString = "Test"
	}.Dump();
	var test2 = test1.Adapt<Test>().Dump();
}

I get an InvalidProgramException with the message Common Language Runtime detected an invalid program. The stack trace is:

   at (ArrayClosure , Object )
   at Mapster.TypeAdapter.Adapt[TDestination](Object source, TypeAdapterConfig config)
   at Mapster.TypeAdapter.Adapt[TDestination](Object source)
   at UserQuery.Main()

Please reopen this and look into it. I have had to temporarily exclude using FEC in my programs using Mapster as a result of this.

CyberBotX on Apr 9, 2021