Issue 1282 - Unexpected result for Float expression with haxe3/neko 2 - haxe

[issuesbot]

[Google Issue #1282 : https://code.google.com/p/haxe/issues/detail?id=1282]
by greg.d...@gmail.com, at 19/11/2012, 04:33:57
What steps will reproduce the problem?
1.See attached Test file, add (temporarily) to haxe unit tests

What is the expected output? What do you see instead?
I expect an explicit Float typed variable or property to be treated as a Float value in neko expressions, even if it has an integer value.

Please complete the following class with minimal code reproducing the
problem :

Please see attached unit.Test subclass

A simplistic example:
var t:Float = 49900;

the above now seems to be treated like an integer.
and neko thinks t*t = -1804957296
whereas other targets calculate it correctly.

Please provide any additional information below.
I am pretty sure this worked correctly (consistent with other targets) with haxe 2.x and neko 1.8.x. I'm not sure whether it's the neko changes or the haxe 3 changes or both that have changed this behaviour.

[issuesbot]

[comment from greg.d...@gmail.com, published at 19/11/2012, 04:57:48]
Sorry. False alarm. Looks like I forgot "-D neko_v2". Please mark invalid.

[issuesbot]

[comment from si...@haxe.org, published at 19/11/2012, 10:08:35]

[issuesbot]

[comment from ncanna...@gmail.com, published at 19/11/2012, 10:33:33]
Actually that might be reproducible with an bigger Int, since neko_v2 does not change that behavior. Opening it again.

[issuesbot]

[comment from greg.d...@gmail.com, published at 19/11/2012, 20:19:36]
Oh sorry again, that was a bit silly of me. Thanks for picking that up. I had commented out the test itself after I updated the define. oops. Yes, it still shows the error, as originally reported, for me even with the v2 define.

[issuesbot]

[comment from ncanna...@gmail.com, published at 09/02/2013, 13:27:39]
This is not an easy fix, since it requires promoting some Int values to Floats when we have an Int-to-Float conversion. It should be handled in genneko.

I'm pushing it for next release.

[issuesbot]

[comment from si...@haxe.org, published at 24/02/2013, 17:12:14]

[deltaluca]

Also happens with results of functions returned from macros in $v{} (example pending).

[deltaluca]

class Macros {
    static public macro function test() {
        return macro $v{testit()};
    }
    static function testit() {
        var x:Float = 10;
        return {x:x};
    }
}

class Main {
    static function main() {
        var x = Macros.test();
        var xs:Array<{x:Float}> = [x];
    }
}

gives error {x:Int} should be {x:Float}

Similar to the inlining problem, adding an ECheckType still doesn't fix things (return ({x:x} : {x:Float}))

[deltaluca]

We 'can' work aroudn this, by adding the ECheckType syntax to the macro function however:

return macro ($v{testit()} : {x:Float});

[ncannasse]

This is perfectly normal since $v does convert a value back to a expression, thus losing the actual orgiinal type it had in the first place.

[deltaluca]

And that is 'not' a good thing.. Ideally $v should insert the ECheckType syntax to enforce the intended type.

In this case though, it should not even be necessary. We should be able to 'fix' this in the interpreter so that var x:Float = 10; has 10 typed with VFloat instead of VInt in the interpreter and we'd output 10. from the macro which would then be inferred correctly as Float.

Generating the correct ECheckType syntax would still be a good thing for when there are abstracts involved though, but there's a whole boat load of things we could do to improve the usefulness of $v

[deltaluca]

Also, before closing, note that the original issue was not about results of $v calls in macro, but the real neko problem that:

inline static var x:Float = 10;

has '10' inlined as an Int, only under neko, every other target correctly inlines it as (10 : Float).

I added the macro problem due to its close relation.

[ncannasse]

The problem is more generalized than that, since neko does not care about compile time types and might overflow if two int values are multiplied, even in the case they were typed as Float