---- Reported by nazgul@omega.pl 2005-04-21 08:14:04 MST ----

Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:
There is an assertion in runtime when I try to generate code similar to
class A <T> {
  A <T> f;
}

using S.R.E.

Steps to reproduce the problem:
1. Compile and run following program (using gmcs)

using System.Reflection;
using System.Reflection.Emit;

class Program
{
static void Main(string[] args)
{
  AssemblyName name = new AssemblyName();
  name.Name = "o";
  AssemblyBuilder builder =
AppDomain.CurrentDomain.DefineDynamicAssembly(name,
AssemblyBuilderAccess.RunAndSave);
  ModuleBuilder mb = builder.DefineDynamicModule("out", "bla.dll");
  TypeBuilder tb = mb.DefineType("MyGenericClass");
  GenericTypeParameterBuilder[] gtbs = tb.DefineGenericParameters("'a");

  Type inst = tb.GetGenericTypeDefinition ().BindGenericParameters (new
Type[] { gtbs [0] });

  FieldBuilder metb = tb.DefineField("foo", inst, FieldAttributes.Public);
  
  tb.CreateType();
  builder.Save("bla.dll");
 }
}


Actual Results:
** ERROR **: file metadata.c: line 2739 (mono_type_size): assertion failed:
(!gclass->inst->is_open && !gclass->klass->generic_container)
aborting...
Aborted


Expected Results:
Clear run

How often does this happen? 
Always

Additional Information:
Obviously gmcs is able to generate mentioned code, so it must be using a
little bit different algorithm for creating field.
But above way seems completely valid and works on MS.NET Beta1 
(after tweaking 
Type inst = tb.GetGenericTypeDefinition ().BindGenericParameters (new
Type[] { gtbs [0] });
to 
Type inst = tb.BindGenericParameters (new Type[] { gtbs [0] });

which is their bug and I guess it's fixed in Beta2)



---- Additional Comments From nazgul@omega.pl 2005-05-04 10:26:31 MST ----

Created an attachment (id=167790)
This patch reliefs the assumption in rutime, which IMHO is not neccessary




---- Additional Comments From nazgul@omega.pl 2005-05-04 10:32:07 MST ----

I've attached the patch, which is moving the assertion that generic
type is closed only to the case of value type. Otherwise, the size of
field containing it is just a pointer size and it does not depend on
the closedness of generic type.

For value types the assertion seems to be feasible, since
struct A <T> {
  A<T> f;
}

is always invalid, also for static fields.



---- Additional Comments From martin@ximian.com 2005-05-10 13:09:11 MST ----

That patch is an absolute no-go.
The assertion is there for a very good reason and removing it would
just introduce tons of problems.



---- Additional Comments From martin@ximian.com 2005-05-10 13:10:14 MST ----

Having 100% S.R.E compatibility with Whidbey is very difficult, a lot
of work and has low priority.



---- Additional Comments From nazgul@omega.pl 2005-05-10 13:22:08 MST ----

Ok, I would appreciate very much if you give a hint for workaround the
problem, because it is blocking our compiler. Otherwise I have to go
into gmcs code and I'm not sure that the final solution is applicable
for me.





---- Additional Comments From malekith@pld-linux.org 2005-05-30 07:38:22 MST ----

We have found that the problem is caused by RunAndSave assembly flag.
This is because of the following code from reflection.c

        if (!((MonoDynamicImage*)klass->image)->run) {
                if (klass->generic_container) {
                        /* FIXME: The code below can't handle generic
classes */
                        klass->wastypebuilder = TRUE;
                        mono_loader_unlock ();
                        return mono_type_get_object
(mono_object_domain (tb), &klass->byval_arg);
                }
        }

So it's clearly a known issue.

It would be nice if this can be fixed, because while this doesn't make
generic emission in our compiler impossible, it will prevent nemish
(interactive nemerle interpreter) from working.

I guess this could be also an issue for booi.




---- Additional Comments From martin@ximian.com 2005-07-04 11:59:53 MST ----

Fixed in SVN.

Imported an attachment (id=167790)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>mono svn from 20 Apr 2005</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".