[Mono-dev] Generic Variance

Rodrigo Kumpera kumpera at gmail.com
Mon Feb 2 11:16:16 EST 2009

On Mon, Feb 2, 2009 at 12:38 PM, Scott Peterson <lunchtimemama at gmail.com>wrote:

> > Why this change is required to make variance works?
> > mono_class_interface_offset is a low level function used mainly to setup
> > vtable layout.
> >
> > This change affects vtable layout code, remoting and reflection. Without
> > proper testing to make sure it doesn't break stuff and is compatible with
> MS
> > this patch is a no go.
> >
> > The chicken and egg situation for testing can be overcome by either using
> IL
> > just for the interfaces, the rest can be done with C#; or you can use
> > System.Reflection.Emit to build types with variance.
> Well, before the change, I tried to execute a legal image with
> variance, and got a runtime error from the mini-trampoline code
> because mono_class_interface_offset returned negative, meaning that
> the offset of the interface for which it was looking could not be
> found on the specified type. However the class did implement a variant
> interface, so I modified mono_class_interface_offset to look for
> variant interfaces if it couldn't find the interface via the usual
> search. There may well be a better place in the VM to handle the
> problem: I just followed the stack trace :) I'll put together an SRE
> test for you to look at.

I gave some thought over lunch to the need for your change and we indeed
need something like it.
The problem is, I don't know if all places should be doing a a generic
variance aware iface offset
query. The vtable layout code is one place where this sounds as wrong.

I think the easer/better solution is to have a variance aware version of
and then incrementally change all spots. This way the testing load will be
incremental and we can
start to move forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090202/10a55106/attachment.html 

More information about the Mono-devel-list mailing list