Support open delegate for Nullable<>

[amos402]

Because of the boxing behavior specialization for Nullable<>, after the boxing, a nullable object may be boxed by the type it referred to or just null, the original type information lost.
For example,

int? num1 = 123;
object box = num1;
// box.GetType() == typeof(int);

int? num2= null;
object box = num2;
// box is null

Thus it's reasonable that a closed delegate binding for Nullable<> such as Delegate.CreateDelegate(invokeType, boxedNullable, method) is prohibited.
However, if for an open delegate case for Nullable<>, the invokeType must point to a delegate in which the first parameter is ref Nullable<XXX>, so it's no need to worry about the type information lost.
Currently, there's a special check for nullable type:

runtime/src/coreclr/src/vm/comdelegate.cpp

Lines 2614 to 2617 in 38bf4df

	// we don't allow you to bind to methods on Nullable<T> because the unboxing stubs don't know how to
	// handle this case.
	if (!pTargetMethod->IsStatic() && Nullable::IsNullableType(pTargetMethod->GetMethodTable()))
	return FALSE;

This specialized check is unnecessary, we can just remove it.
case 1: a closed delegate with boxed nullable value, no matter which type it would be, it just can't pass the type validation because the type won't match the nullable type.
case 2: an open delegate targeted by xx Func(ref Nullable<XXX> self), the self type for the target method would use its reference type, the fromHandle and toHandle pass to IsLocationAssignable would be the same one.
It makes the code like as follow can't be used on .NetCore(.Net framework as well), on the other side, mono can.
The present version throws an ArgumentException for these cases.

delegate bool HasValueDelegate(ref int? obj);
delegate int GetValueDelegate(ref int? obj);
delegate string ToStringDelegate(ref int? obj);

static void Main(string[] args)
{
    int? num = 123;
    Type type = typeof(int?);
    {
        var mHasValue = typeof(int?).GetProperty("HasValue").GetMethod;
        var HasValue = (HasValueDelegate)Delegate.CreateDelegate(typeof(HasValueDelegate), mHasValue);
        Console.WriteLine("HasValue: {0}", HasValue(ref num));
    }

    {
        var t2 = (GetValueDelegate)Delegate.CreateDelegate(typeof(GetValueDelegate), type.GetProperty("Value").GetMethod);
        int value = t2(ref num);
        Console.WriteLine("Value: {0}", value);
    }

    {
        const BindingFlags MethodFlag = BindingFlags.Public | BindingFlags.Instance;
        var mGetValueOrDefault = typeof(int?).GetMethods(MethodFlag)
            .Single(m => m.Name == "GetValueOrDefault" && m.GetParameters().Length == 0);
        var GetValueOrDefault = (GetValueDelegate)Delegate.CreateDelegate(typeof(GetValueDelegate), mGetValueOrDefault);
        Console.WriteLine("GetValueOrDefault: {0}", GetValueOrDefault(ref num));
    }

    {
        var mToString = type.GetMethod("ToString");
        var ToString = (ToStringDelegate)Delegate.CreateDelegate(typeof(ToStringDelegate), mToString);
        Console.WriteLine("ToString: {0}", ToString(ref num));
    }
}

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[dnfadmin]

All CLA requirements met.

[davidwrighton]

/azp list

[azure-pipelines]

CI/CD Pipelines for this repository:

• coreclr-gc-longrunning
• coreclr-gc-simulator
• runtime-coreclr outerloop
• runtime-coreclr r2r-extra
• runtime-coreclr r2r
• runtime-coreclr runincontext
• runtime-coreclr crossgen2
• runtime-libraries-coreclr outerloop
• runtime-libraries-coreclr outerloop-windows
• runtime-libraries-coreclr outerloop-linux
• runtime-libraries-coreclr outerloop-osx
• runtime
• runtime-libraries enterprise-linux
• runtime-libraries stress-http
• runtime-libraries stress-ssl
• runtime-live-build
• runtime-coreclr crossgen2 outerloop
• coreclr-release-outerloop-nightly
• sync-runtime-to-mono
• dotnet-runtime-perf
• runtime-coreclr crossgen2-composite
• runtime-jit-experimental
• runtime-coreclr libraries-jitstress
• runtime-coreclr libraries-gcstress0x3-gcstress0xc
• runtime-coreclr libraries-gcstress-extra
• dotnet-linker-tests
• runtime-coreclr ilasm
• runtime-coreclr clrinterpreter
• runtime-coreclr crossgen2-composite gcstress
• runtime-libraries-mono outerloop
• runtime-coreclr superpmi
• runtime-coreclr jitrollingbuild

[davidwrighton]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ViktorHofer]

// Auto-generated message

69e114c which was merged 12/7 removed the intermediate src/coreclr/src/ folder. This PR needs to be updated as it touches files in that directory which causes conflicts.

To update your commits you can use this bash script: https://gist.github.com/ViktorHofer/6d24f62abdcddb518b4966ead5ef3783. Feel free to use the comment section of the gist to improve the script for others.

[mangod9]

@davidwrighton and @lambdageek will follow up on this.

[davidwrighton]

@lambdageek This change looks good from the coreclr point of view, but I'm not prepared to merge with a comment about what you'd like done for the mono interpreter. I could disable the test for the interpreter runs and for wasm, or either you or @amos402 could look into fixing the interpreter.

[lambdageek]

@davidwrighton Please disable the test and ping me with the issue. The interpreter has a separate path through our (convoluted) delegate code and I don't think it's necessary to hold up this PR.

[davidwrighton]

This is a good change. I'd like to apologize for how long it took for us to get started on review of it.