---- Reported by carlos@unixmexico.org 2005-08-23 19:40:14 MST ----

The runtime executes the 'is' statement the worng way with generics.

Compile the app below with gmcs:

====================
using System;
using System.Collections;
using System.Collections.Generic;

 public class B : IComparable<B> {
         public int CompareTo (B b)
         {
                 return 0;
         }
 }

 public class Tester {

         static void Main ()
         {
                 B b = new B ();

                 // This should be false
                 if (b is IComparable<object>)
                         Console.WriteLine ("b is IComparable<object>");
         }

 }
==============

Actual Results:
b is IComparable<object>

Expected Results:
Nothing.

How often does this happen? 
Always.



---- Additional Comments From miguel@ximian.com 2005-09-05 23:51:02 MST ----

Martin, sorry another generics bug for you.



---- Additional Comments From malekith@pld-linux.org 2005-09-06 07:20:09 MST ----

I'm also interested in this bug, so I added myself to Cc:. I hope it's OK.



---- Additional Comments From martin@ximian.com 2005-09-06 09:55:27 MST ----

This is a mini bug - in CEE_ISINST, we need to check whether one of
the types is a generic instance and then use some other comparision
function (which still needs to be written).



---- Additional Comments From malekith@pld-linux.org 2005-09-06 11:03:56 MST ----

Please note that this special handling is only required in certain
cases. For example here:

class A<T> { }
class B<T> : A<T> { }

test (A<int> a) {
  if (a is B<int>) { ... }
}

the usual handling is just fine, becasue if we statically know the
value is of type A<int> and it's B, then it's B<int>.

To be precise the situation is when we know the value is of type T1,
T2 is subtype of T1 and all generic parameters of T2 are used in
subtyping declaration of T2, though I would be still happy if only the
case of T2<p1,...,pn> : T1<p1,...,pn> was handled this faster way.

I'm marking this because this check is performance critical for
Nemerle code.




---- Additional Comments From martin@ximian.com 2005-10-28 18:24:52 MST ----

ASSIGNED -> NEW



---- Additional Comments From vargaz@gmail.com 2005-11-16 13:24:43 MST ----

The problem here is that
mono_get_unique_iid () allocates the same id to all instantinations of
a generic class, it should probably use  mono_type_get_name_full ()
for obtaining the name.




---- Additional Comments From vargaz@gmail.com 2005-11-16 16:46:02 MST ----

This also means that two instantinations of the same generic type will
have different max_interface_id, and interface_offsets fields, so
setup_generic_vtable () needs to change.




---- Additional Comments From martin@ximian.com 2005-12-08 13:37:28 MST ----

This one is next.



---- Additional Comments From martin@ximian.com 2005-12-14 18:09:56 MST ----

Fixed in SVN.



---- Additional Comments From martin@ximian.com 2005-12-15 11:34:41 MST ----

Fixed :-)

This bug blocked bug(s) 76361.

Unknown operating system unknown. Setting to default OS "Other".