Fix problem on linux mono environment.

[kekyo]

Reduced failure case down to 36 (net5.0 is 24) now.

[kekyo]

net48 regression test on linux/mono

  Failed Remove_EntireMatchedMulticastDelegate(1000) [1 s]
  Error Message:
   System.IndexOutOfRangeException : Index was outside the bounds of the array.
  Stack Trace:
    at (wrapper delegate-invoke) <Module>.invoke_void_int&(int&)
  at IL2C.BasicTypes.System_Delegate.Remove_EntireMatchedMulticastDelegate (System.Int32 value) [0x00077] in <fe2de562cdb04b2fb48efe67bd8d6c8d>:0 
  at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
  at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0007c] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 

Maybe causes at:

 // (dlg1 + dlg2 + dlg3) - (dlg1 + dlg2 + dlg3) = null
 var dlg = (IntRefDelegate)Delegate.Remove(dlgA, dlgB);

 var v = value;
 dlg?.Invoke(ref v);

It's strange error running on mono CLR... mono has a bug? The 'dlg' will be set 'null', but 'Delegate.Remove' also returns valid instance...

TestCase attribute has to be settable ignoring flag when detecting execution platform...

[kekyo]

Omitted dotnet-ilverify and switched to Il.Verification library. Because failure regression test isn't easy searched from error message text, and couldn't set ad-hoc ignoring verification error.

When detect IL error, the test engine produce with message like:

IL2C.BasicTypes.System_Object.ToString: [ThisMismatch/None]: The 'this' parameter to the call must be the calling method's 'this' parameter.: Offset=1: [0x0001]: Call

New style can set ignoring parameter onto TestCase.IgnoreILErrors property. For example, set it to "ThisMismatch", above case is silently ignored.

[kekyo]

I found some verification problem cases:

• Surprised ILAsm is required distinguish type name between registered CLR type name (byte, string, object...) and formal type name ([netstandard]System.Byte, [netstandard]System.String, [netstandard]System.Object). Have to fix many IL source code, but easy to fix by simple text replacing.
• box opcode is required push same type into evaluation stack. For example: box int16 required before conv.i2.
• call (not callvirt) is required instance argument coming from current method this reference. ILVerify tracks from ldarg.0 evaluation stack with marking this:

public class Foo
{
    // OK (with `callvirt`)
   public static string Foo(object obj) =>    // static method
       obj.ToString();    // uses `callvirt`

    // NG (with `call`)
   public static string Foo(object obj) =>    // static method
       obj.ToString();    // uses `call`: causes `ThisMismatch`

    // OK
    public string Bar() =>   // instance method
        base.ToString();  // uses `call`
}

In this case, I will ignore strictly checking.

[kekyo]

Strange error:

public static string ToString(bool value)
{
       return value.ToString();
}

It causes:

IL2C.BasicTypes.System_Boolean.ToString: [StackUnexpected/None]: Unexpected type on the stack.: Offset=3,Found=address of Boolean: [0x0003]: Call

It will be generated by only Roslyn, I feel it isn't any mistakes. I will plan how to exclude implicitly these error patterns.

• Turn to regex matching at IgnoreILErrors checking.
• Produce default implicit exclude rules inserting into TestFramework.ExecuteTestAsync.

[am11]

Omitted dotnet-ilverify and switched to Il.Verification library.

Just in case it is not obvious, both dotnet-ilverify and its backing library, IL.Verification, are considered as preview features in runtime repo. The verification does not currently pass on Shared Framework (sfx) libraries even. There are opened issues / pending work to make it production ready: https://github.com/dotnet/runtime/issues?q=is:open+is:issue+label:area-ILVerification.

[kekyo]

Thank you for information. During my research, I learned that this is a corert-derived code. As a matter of fact, many inappropriate warnings are returned, so I am thinking about how to handle it...

(The embedding itself is working fine and I feel sorry to remove it, so for now I'm going to take the approach of disabling defaulted)