`Func<T>.MakeGenericType(typeof(ReadOnlySpan<char>))` throws `ArgumentException` in 7.0.100-preview.4 while the exception was `TypeLoadException` in prior versions

[daxian-dbw]

Description

Func<T>.MakeGenericType(typeof(ReadOnlySpan<char>)) (or calling MakeGenericType with any other byref-like value types) throws ArgumentException in 7.0.100-preview.4 while the exception was TypeLoadException in prior versions.

It turns out the ArgumentException wraps a TypeLoadException in its inner exception property.

Reproduction Steps

In PowerShell with 7.0.100-preview.4:

PS:> try { [Func`1].MakeGenericType([System.ReadOnlySpan[char]]) } catch { $a = $_ }
PS:> $a.Exception.InnerException.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     ArgumentException                        System.SystemException

In PowerShell with .NET 6 and prior 7-preview versions

PS:> try { [Func`1].MakeGenericType([System.ReadOnlySpan[char]]) } catch { $a = $_ }
PS:> $a.Exception.InnerException.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     TypeLoadException                        System.SystemException

Expected behavior

Throw TypeLoadException as in the prior versions.

Actual behavior

Throw ArgumentException in 7.preview-4
Not sure if this is an intentional change, or a real regression.

Regression?

Yes

Known Workarounds

We can work around by catch all exceptions.

Configuration

No response

Other information

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

cc @AaronRobinsonMSFT Likely related to #67783

[AaronRobinsonMSFT]

@daxian-dbw In my mind this is by-design. I agree it is a breaking change, but it is because we are adding a new type of generic constraint check. In this case that is support for generics to be ByRefLike, the link provided in #69084 (comment) is the PR introducing runtime support.

@jkotas The error is technically correct because the argument is violating the new constraint we added. The new check for this violation is at

runtime/src/coreclr/vm/typedesc.cpp

Lines 1526 to 1527 in 6d23405

	if (thArg.IsByRefLike() && (specialConstraints & gpAcceptByRefLike) == 0)
	return FALSE;

which is then translated in

runtime/src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs

Lines 1991 to 1996 in 6d23405

	if (!RuntimeTypeHandle.SatisfiesConstraints(genericParameter.TypeHandle.GetTypeChecked(),
	typeContext, methodContext, genericArgument.TypeHandle.GetTypeChecked()))
	{
	throw new ArgumentException(
	SR.Format(SR.Argument_GenConstraintViolation, i.ToString(), genericArgument, definition, genericParameter), e);
	}

Adding @davidwrighton for thoughts too.

[davidwrighton]

I never like changing existing error behavior, its bound to break somebody, but given the new feature, changing how this errors out isn't unreasonable. @daxian-dbw could you explain your scenario in more detail? I'd like to know more about why your code calls the api with these arguments. I don't like suggesting catching all exceptions as a good mitigation, but that may be reasonable in your codebase.

[daxian-dbw]

See the code here: https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/MshMemberInfo.cs#L2694

It creates a Func<...> type for every .NET method overload processed by PowerShell, to support directly passing [M]::DoubleStrLen to the [func[string, int]] parameter in the below script example.

class M {
    static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }
    
    static [long] AggregateString([string[]] $values, [func[string, int]] $selector) {
        [long] $res = 0
        foreach($s in $values){
            $res += $selector.Invoke($s)
        }
        return $res
    }        
}

[M]::AggregateString((gci).Name, [M]::DoubleStrLen)

I think in our use case, it's safe to change to catch (Exception) because we indeed want to return typeof(Func<PSNonBindableType>), which indicates this overload cannot be converted to any Func<...> type, in case the creation the Func delegate type fails.

[AaronRobinsonMSFT]

@daxian-dbw Thanks for explaining your use case. Based on the statement above it sounds like you accept this as a valid change in behavior. I would agree in that we are expanding support so we can provide more precise failure details. In this case ByRefLike types are supported in generics - at least from the runtime perspective.

As far as the PowerShell code, It might be more appropriate to separate the two cases, TypeLoadException and a failure to satisfy a Generic constraint (i.e., ArgumentException).

I'm going to close this as by-design for now, please let us know if you have a concern about the resolution.

[daxian-dbw]

In this case ByRefLike types are supported in generics - at least from the runtime perspective.

@AaronRobinsonMSFT Does this mean ByRefLike types will be generally supported to be used as generic arguments? In that case, why would an ArgumentExcpetion be thrown in case of calling MakeGenericType with a ByRefLike type?

The following script attempts to create Span<Span<char>>, with the .NET 7.100-preview.4

PS:16> try { [System.Span`1].MakeGenericType([System.Span[char]]) } catch { $a = $_ }
PS:17> $a.Exception.InnerException.InnerException

Message        : GenericArguments[0], 'System.Span`1[System.Char]', on 'System.Span`1[T]' violates the constraint of
                 type parameter 'T'.
TypeName       :
TargetSite     : Void Instantiate(System.Runtime.CompilerServices.QCallTypeHandle, IntPtr*, Int32,
                 System.Runtime.CompilerServices.ObjectHandleOnStack)
Data           : {}
InnerException :
HelpLink       :
Source         : System.Private.CoreLib
HResult        : -2146233054
StackTrace     :    at System.RuntimeTypeHandle.Instantiate(QCallTypeHandle handle, IntPtr* pInst, Int32
                 numGenericArgs, ObjectHandleOnStack type)
                    at System.RuntimeType.MakeGenericType(Type[] instantiation)

[AaronRobinsonMSFT]

Does this mean ByRefLike types will be generally supported to be used as generic arguments?

Yes, but it can only be achieved via IL at present. The C# language team is working through support, but that will likely come in post C# 11.

In that case, why would an ArgumentExcpetion be thrown in case of calling MakeGenericType with a ByRefLike type?

Because Span<> hasn't been updated to say it supports that feature because there is no way to express that in C# yet. Once that support is added to the language this particular case would work.

[daxian-dbw]

@AaronRobinsonMSFT Thanks for the clarification! That helps 😄