The runtime type of polymorphic values is always ENCORE_PRIMITIVE

[EliasC]

The following program has a polymorphic class that stores another polymorphic class:

passive class Foo<t>
  f : t

passive class Bar<t>
  f : Foo<t>

  def init() : void
    this.f = new Foo<t>

class Main
  def main() : void
    ()

Looking at the generated function for the constructor of Bar, we see that a new Foo is created, whose runtime type is ENCORE_PRIMITIVE:

void* _enc__method_Bar__init(_enc__passive_Bar_t* _this)
{
  _enc__passive_Foo_t* _new_0 = encore_alloc(sizeof(_enc__passive_Foo_t));
  _new_0->_enc__self_type = (&(_enc__passive_Foo_type));
  _enc__type_init_Foo(_new_0, ENCORE_PRIMITIVE);
  _enc__method_Foo__init(_new_0);
  (*({ _this;}))._enc__field_f = _new_0;
  return UNIT;
}

Of course we cannot assume that the type parameter t will always be a primitive, since it means that the field f in Foo will never be traced! We have similar problems when using polymorphic arrays (replace Foo<t> by [t] to see the problem). Replacing ENCORE_PRIMITIVE by _this->_enc__type_t solves the problem.

The translation from encore types to runtime types is performed in CodeGen.Type, and for type variables it hets the default case, which is ENCORE_PRIMTIVE (it should probably be an error instead so that we can avoid these problems in the future). In polymorphic classes, the runtime types of the type parameters are stored in fields (see above), but this won't be the case when we have polymorphic functions and methods. Currently we have polymorphic anonymous functions, but there the runtime type of type parameters are not available (which probably causes bugs already). I suggest we "fix" this temporarily by translating type variables to the field lookups mentioned above and live with the buggy anonymous functions until we fix them properly (together with polymorphic functions).

[TheGrandmother]

This horrible code probably suffers from this error.

The closure on line 33 in PrefWat.enc does not seem to be traced properly and causes things to behave oddly.

https://gist.github.com/TheGrandmother/377e4444afe7d646bb28e5aed354a453

[albertnetymk]

I thought this issue is resolved by b521e97.

[TheGrandmother]

@albertnetymk
Nope it doesn't look like it. I have tested it on both the latest development branch and the new-ponyrt branch and it doesn't work :/