Simon Krajewski

I don't see why it would check any mtimes if run through vshaxe, because vshaxe disables exactly that: ``` Processing Arguments [--times,-D,macro-times,--display,{"jsonrpc":"2.0","id":1,"method":"server/configure","params":{"noModuleChecks":true,"print":{"completion":true,"reusing":false},"legacyCompletion":false}}] ``` The `"noModuleChecks":true` puts the compiler in dumb...

That's interesting. I'm not sure how DCE can affect a generator like that. You can try setting the environment variable `OCAMLRUNPARAM=b` and see if that gives you a full stack...

This comes up every once in a while. Maybe we could add a `#if (haxe_ver < current)` check to Std.hx.

Am I reading this correctly that it's (also) complaining about `java.lang.Iterable` not conforming to `java.util.List`?

That means we have three issues here: 1. We shouldn't check a native lib type during type-loading. 2. Even if we do, there's clearly some bad inference going on. 3....

Ooooh `spliterator` has `@:java.default`, that changes everything.

I've fixed one issue. Another is that these type parameters seem to have an implicit constraint to `java.lang.Object`, which causes the redefinition check to fail. Your example no longer emits...

I don't want to actually insert the constraint because that would just waste everyone's time and memory, but we can allow a redefinition that omits it. Actually, I think constraints...

I kind of already forgot what conclusion we reached here, but this is not as buggy as it might look due to function argument contravariance.

Hmm, well, these overloads already don't compile to real overload targets because of this: ``` source/Main.hx:7: lines 7-8 : Another overloaded field of similar signature was already declared : test...