Simon Krajewski
Simon Krajewski
I'm not closing this one even though it's Java/C# specific, because the AST looks wrong here.
I don't have android studio to test this, but jclasslib says that `hx.concurrent.executor.Executor$Closure_new_0` only exists once. Although I don't know if it somehow filters duplicates. I also don't understand why...
Actually I have an idea why this could happen. Could you try if this reproduces the issue: ```haxe class Parent { public function new() {} } class Child extends Parent...
I found a way to test this by using overloads, which I think should be the exact same issue: ```haxe class Test { overload static public function test() { function...
See if that helped. Nightly builds are available (at some point) at https://build.haxe.org/builds/haxe/. The fix avoids the problem, but it's not perfect for the original issue. This is (I think)...
I've pushed another change for that. It seems strange to me that fields are special here and generating signatures for basic types would cause warnings, but that's indeed what the...
I'm assuming that this has been addressed. Please let me know if there's still a problem!
Hmm, interesting. I suppose I'll have to find a way to reproduce that without installing Android Studio. I wonder why the normal verifier doesn't catch this.
IMO we should discuss dropping this "constant" restriction entirely. From what I understand, this originally came from limitations the flash run-time had, but I don't see any reason why we...
I don't think hxparse is the right place to fix this, haxeparser is more appropriate.