Closed Type1J closed 9 years ago
... It looks like this is not the only place in Away3D that hxcpp has this problem. There are many other places, but similar workarounds still exist, and work correctly.
Thanks for raising these issues .... Are you experiencing this on haxe 3.2? I've not tried 3.2 yet (hence the problems) and am not experiencing the same issues that I'm aware of using 3.1.3.
Sorry, yes, I added "On Haxe 3.2" to the original comment, now.
I can take a look if someone posts a minimal reproducible example.
@Simn: Here's an example: build.hxml:
-js AssignmentTest.js
-main AssignmentTest
--next
-swf AssignmentTest.swf
-main AssignmentTest
--next
-cpp AssignmentTest
-main AssignmentTest
AssignmentTest.hx:
class AssignmentTest {
public static function main():Void {
trace("Start: ");
var i:Int;
var b = true;
while (b && ((i = 18) < 18)) {
trace(" Assignment! ");
++i;
}
}
}
An "haxe build.hxml" yields AssignmentTest.js, AssignmentTest.swf, and when it gets around to hxcpp:
AssignmentTest.hx:8: characters 8-9 : Local variable i used without being initialized
I thought that it might not happen with primitives, or that it only happens with monomorphs, but it happens with well defined primitives as well.
Changing the reference to b in the loop condition to a bool literal of true removes the error. However, if it's a variable at all, the data flow analysis somehow misses that after the &&, i is assigned, and that code is required to be executed before the conditional use of i (++i on line 8).
https://github.com/openfl/openfl/blob/master/openfl/utils/AGALMiniAssembler.hx around line 283 had this error as well, until a recent change that initialized t to null before the while condition.
Fixed in Haxe.
@Simn: Thanks! @Greg209: When you do start using Haxe 3.2, there should be no code changes in Away3D necessary for this issue, so I'm closing it now.
Awesome !!!!!
On Haxe 3.2: This compiles to Flash correctly, but when compiling to C++:
I think the compiler isn't seeing line 331, which is just above this code, as an initialization:
There is an assignment to particle, but the compiler just isn't happy with it.
A work around is:
I'm guessing that this is an hxcpp bug, but it has an easy work around. I'm posting an issue for hxcpp, but until that gets fixed, this workaround may be necessary.