TCast issue with abstract casts in Typed Ast

[frabbit]

abstract X(Int) from Int to Int {}

class Main {
   public static function foo(x:X) {}
   public static function main () {
     foo(1); 
     // it seems that the argument becomes TCast(1, None) 
     // in the typed ast, but it has the type Int instead of X.
    // which means generators cannot access the real type of the
    // cast expression (in this case X). It could also have other side effects.
  }
}

excerpt IRC:

[14:17] <Simn> Hmm, I don't want to add that to the core compiler at the moment.
[14:18] <Simn> Can we do this in check_unification?
[14:18] <frabbit> you mean the cast problem?
[14:19] <frabbit> is loosing the real type a bug in that case? is it inline related?
[14:19] <Simn> Yes
[14:20] <Simn> I don't see why you're saying it loses the real type...
[14:20] <Simn> The real type is Dict, no?
[14:20] <frabbit> yes, but the type of the argument is KwArgs
[14:21] <frabbit> because the functions expects KwArgs
[14:21] <Simn> But then the real expression type is still Dict.
[14:21] <frabbit> and the compiler wraps a cast around it which should have the type KwArgs
[14:22] <frabbit> but i guess it still have the type Dict
[14:23] <frabbit> but i can work around that and use check_unification when the expected type is KwArgs
[14:24] <frabbit> i'm pretty sure that i had a related bug sometime ago in combination with inline
[14:28] <Simn> I don't know if I want to add something like this to the core compiler in a patch release...
[14:29] <Simn> Couldn't we dodge the issue by using @:from and @:to in KwArgs instead?
[14:31] <frabbit> yes, i already done that here, it works fine this way
[14:31] <Simn> You can open an issue for the general case, I'll check it for 3.2.
[14:31] <Simn> It's a bit too intrusive right now.
[14:31] <Simn> Although I'll admit that it does make sense that way.

[Simn]

We can add the TCast for 3.2, right now it makes me too nervous.

[Simn]

I tried adding this but ran into Java overload issues. I'll have to check what's going on there.

./unit/TestJava.hx:103: characters 2-22 : This call is ambiguous between the following methods:
../unit/TestJava.hx:103: characters 2-22 : Function 'normalOverload' with type param1 : Int -> Void
../unit/TestJava.hx:103: characters 2-22 : Function 'normalOverload' with type param1 : Dynamic -> Void
../unit/TestJava.hx:103: characters 2-22 : Function 'normalOverload' with type param1 : Single -> Void
../unit/TestJava.hx:103: characters 2-22 : Function 'normalOverload' with type param1 : Float -> Void

cc @waneck

[Simn]

Assigning to @waneck as I don't understand the issue. To reproduce comment in the TCast line here: https://github.com/HaxeFoundation/haxe/blob/development/codegen.ml#L699

[frabbit]

I have a test case for this issue:

class Test {

  public static function main ()
  {
    function x (args:python.KwArgs) {
      return 0;
    }
    // this works the generator receives KwArgs as the type
    var a = python.Lib.anonToDict({ "a" : 1, "b" : 2});
    var res = x( a );

    // this fails at runtime because the generator gets the type dict instead of KwArgs.
    var res = x( python.Lib.anonToDict({ "a" : 1, "b" : 2}) );

  }
}
// generated python code ( see generated ** )

/*
class Test:
  @staticmethod
  def main():
    def _hx_local_0(**args):
      return 0
    x = _hx_local_0
    a = python_Lib.anonToDict(_hx_AnonObject({'a': 1, 'b': 2}))
    res = x(**a)
    res1 = x(python_Lib.anonToDict(_hx_AnonObject({'a': 1, 'b': 2})))
*/