Variance type hole with core-type abstracts

[Simn]

We currently allow this to compile:

class Main {
    static public function main() {
        var a:Array<Int> = [];
        var b:Array<Float> = a;

        var a:Array<UInt> = [];
        var b:Array<Int> = a;
    }
}

There is a bug in the unification handler because core-type abstracts should not allow this kind of variance. The problem is that UInt has @:coreType on some platforms (flash and cs), but not on others. This would lead to inconsistent behavior.

I don't know what to do with this right now...

[ncannasse]

Ouch that's a huge regression compared to Haxe 2.10 Why is the Float/Int allowed ? they are two different core types, they should not be type_eq

[Simn]

This was an oversight from me trying to fix the mess your UInt merge caused. It's a very easy fix, but the UInt issue remains.

I'll go ahead and re-enable the unification behavior right now and leave this issue open for UInt.

[Simn]

Also we should hire some intern to add TCoreType. They have special semantics in virtually every single place.

[Simn]

So the current problem is this:

class Main {
    static function main() {
        var a:Array<UInt> = [];
        var b:Array<Int> = a;
    }
}

Right now this is allowed on neko and co because there UInt is defined with Int as the underlying type, which allows variance. It is not allowed on flash because there UInt is a core-type.

[Simn]

So I "think" I dealt with both the original issue and the UInt inconsistency. I'm still nervous about this, but we will see how it goes.

[Simn]

Actually I've changed my mind. I'll keep the type hole closed but revert everything related to UInt. Turning it into a @:coreType is not so easy because it requires all the generators to be aware of the type. Making it a non-core-type on Flash is also not easy because we don't want to base it on Int there.

[Simn]

Actually the original issue here is fixed. I'll close this and open a new issue for UInt later.