Type test for ref struct is incorrect

[iskiselev]

If ref struct G<T> defined, this type test inside the struct for any resolved generic returns false (and compiler not even add test in IL).
It also shows warning CS0184 and does not allow to use it in pattern math type test.

Version Used: C# 10

Steps to Reproduce:

Compile and run next code:

Use next code:

using System;

new G<int>().Test();
new G<object>().Test();

ref struct G<T>
{
    public void Test()
    {
        if (this is G<int>)
        {
            Console.WriteLine("int");
        }
        else if (this is G<object>)
        {
            Console.WriteLine("object");
        }
        else
        {
            Console.WriteLine("unknown");
            Console.WriteLine(typeof(T));
        }
    }

    /*public void TestPattern()
    {
        var genericTypePattern = this switch
        {
            G<int> => "int",
            G<object> => "object",
            _ => "unknown"
        };

        Console.WriteLine(genericTypePattern);
    }*/
}

On SharpLib.IO

Expected Behavior:
Program should output:

int
object

No CS0184 warning should not be shown, if uncomment, TestPattern method should compile without errors.

Actual Behavior:
Program outputs:

unknown
System.Int32
unknown
System.Object

CS0184 warning shown, TestPattern method can not be compiled without changes

[AlekseyTs]

In order to perform a runtime type test, a value type must be boxes, but ref-structs cannot be boxed. Perhaps instead of producing a warning for is operator, we should be producing an error rather than assuming that an unsupported type test always fails?

[AlekseyTs]

@jaredpar, @MadsTorgersen What do you think?

[MadsTorgersen]

I think it should be an error. That way we preserve our ability to do it right later without changing semantics.

Also the current result is just plain wrong!

[jaredpar]

@AaronRobinsonMSFT @davidwrighton

In order to perform a runtime type test, a value type must be boxes, but ref-structs cannot be boxed

This is a good point. Is there a way to safely type test a ref struct when generics are involved like this?

I think it should be an error. That way we preserve our ability to do it right later without changing semantics.

Generally agree with this in the short term.

[AaronRobinsonMSFT]

Boo. I didn't realize these all compile down to IL. @jaredpar I get your question now.

[AlekseyTs]

@AaronRobinsonMSFT Scenario that you are trying is different and compiler behaves differently. It handles identity case specially, I think.

[davidwrighton]

One possible approach to get the desired behavior is something like this, using typeof instead of is ... https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEUCuA7AHwAEAmARgFgAoavGAdwAIBxAHgEs8MA+ACgEoAdABUYAZwwCA3LQYtWEYACsYYHgJHjJ/GTSqwAZowm4184d2oBvaozuMiAZgcpGoiQNv2bVe38bsRrwYAJ4ADjAQBrxsFvyMALwJjKERUTEcXNz8/F7+jD75+URkAJy8AEScGBU6ef4AvvV+MAA2YjABQamR0bHZick96WyKKmrZub5FhUV+JeUVY6o1ddP5Tev+bR3N3nvFZZX4ANZ4EPR4tbpz80fD0cI5N0Wbfpv1APQAVE4ubloAAoAQwwGBgUDwni2s3yADdgVBGABzGB0KDsMDCcIwEFgiF4RIpAAW7DExno7AwYGJBwKdL8bGq3ESLKqXAqaAZ9lGyhWLISbOWak53LsAH1WYwKqdzpcKnSGro6QteKj0ZjsRE8eDIWt3t9PtQGkA

[iskiselev]

I'd like to share some context how I come to this issue, if it will help.
I've implemented custom InterpolatedStringHandler for my logger. The logger has interface with separate Trace, Debug, Info, ..., methods. The handler should return false if current log level is bellow level that will be written by logger. As the only different thing is LogLevel, I thought I will be able to move it to generic class function and will have something like:

interface ILogger {
 void Trace([InterpolatedStringHandlerArgument("")]LogInterpolatedHandler<TraceLevel> handler);
 void Debug([InterpolatedStringHandlerArgument("")]LogInterpolatedHandler<DebugLevel> handler);
...
}

I come up with if block typeof(T) == typeof(TraceLevel) and so on (as suggested in previous comment by @davidwrighton), but it was slower, than using just separate class for interpolated handlers. I thought that with this test it may work faster and, probably, JIT will be able to eliminate check and non-used branches, if ...Level classes would be value types.
I believe my original problem would be solved by abstract interface method (with code used in #63617), but it would not work on older runtimes (while interpolated string handler works perfect).

[AaronRobinsonMSFT]

Seems we have 2 questions here.

1. Can this be done at present? Yes, but one needs to use typeof(G<T>) == ... instead of is which is a potential boxing IL sequence operation when the "might be" equivalence is present.

2. Do we have an IL sequence to express this that will be elided at run-time? At present no, but once we fully support ByRefLike types as generic parameters we will have a sequence. See TypeSystem: Support ref structs within generics runtime#65112.

[jkotas]

typeof(G<T>) == ... is recognized by the JIT optimizations and elided where possible.

[iskiselev]

At least it is not eliminated now for that case, per https://sharplab.io/#v2:EYLgtghglgdgNAFxBAzmAPgAQEwEYCwAUETAKYDuABAOIA8sCAfABQCUAdAEoCuMbA3CQo1aAMwA2AewhM2XXgKFU6DFhx4wAouKhhYM0gBNFxQgCdSoyigRnuAYwQiAKowDeRSpUwBmbwBZKDTYPQi9wyigrZgQATwAHUklRZjpXVkoAXkzKOMTk1PoYJlZWNwiKzwqIzFwATmYABgAPCAhG3FZBMIqAXyqIqMoYhKSUtMYM7NzRgroJaRKygerveqbW9uwula9+nv2vXwCg3m1dfQQjEOrd2oaWtsbGnYOiXqA

Ok, I'm wrong - it is eliminated:
https://sharplab.io/#v2:EYLgtghglgdgNAFxBAzmAPgAQEwEYCwAUETAKYDuABAOIA8sCAfABQCUAdAEoCuMbA3CQo1aAMwA2AewhM2XXgKJEATqVGUUCZdwDGCEQBVGAbyKVKmAMwWALJR59WpwudeUo65ggCeAB1KSosx0RqyUALzhlD7+gcH0MEysTm6pZqlumLgAnMwADAAeEBB5uKyCLqkAvulupOIopJTOGZk5+UUl2OW1rjWV/VVAA===