extern/generic/abstract generates invalid code

[jonigata]

compile.hxml

-cs tmp
-main AbstractExtern
-D no-compilation
-D no-root

AbstractExtern.hx

@:native('System.Collections.Generic.List')
extern class CSharpList<T> {
    public var Count(default, null): Int;
    public function get_Item(n: Int): T;

}

abstract List<T>(CSharpList<T>) from CSharpList<T> to CSharpList<T> {
    public var Count(get, never): Int;
    public function get_Count(): Int {
        var l: CSharpList<T> = this;
        return l.Count;
    }
    public function get_Item(n: Int): T {
        var l: CSharpList<T> = this;
        return l.get_Item(n);
    }
}

class AbstractExtern {
    public static var l: List<Int>;

    public static function main() {
        trace(l.get_Item(3));
    }
}

generated code(partial)

        public static void main() {
            unchecked {
                #line 24 "/Users/life2bits/Grande/client/haxe/SandBox/externabstract/AbstractExtern.hx"
                global::haxe.Log.trace.__hx_invoke2_o(((double) (global::_AbstractExtern.List_Impl_[$type_param, global::haxe.root.AbstractExtern.l, 3]) ), global::haxe.lang.Runtime.undefined, default(double), new global::haxe.lang.DynamicObject(new int[]{302979532, 1547539107, 1648581351}, new object[]{"main", "AbstractExtern", "AbstractExtern.hx"}, new int[]{1981972957}, new double[]{((double) (24) )}));
            }
            #line default
        }

What is $type_param?

[nadako]

Somewhat reduced example:

abstract List<T>(cs.system.collections.generic.List_1<T>) {
    public function get_Item(n:Int):T {
        return this.get_Item(n);
    }
}

class Main {
    public static function main() {
        var l:List<Int> = null;
        var v = l.get_Item(3);
    }
}

generated code:

global::_Main.List_Impl_[$type_param, ((global::System.Collections.Generic.List<int>) (null) ), ((int) (3) )];

Looks like the issue here is that get_Item shouldn't be generated as a [] operator for abstract implementations. The $type_param argument is an internal hack for generating concrete T for call<T>() based on expected type (since Haxe doesn't support call<T>(...) syntax).

@waneck are we going to do something about this for 3.3?

[waneck]

Unfortunately not that simple to fix - we need to change all these special names because otherwise C# thinks they are operators and doesn't let us call them anyway