Closed aliokan closed 5 years ago
Hmm, seems that haxe.rtti
chokes on this js-specific <icast />
:
<abstract path="tink.core.Future" params="T" file="...">
...
<from>
...
<icast field="ofJsPromise"><c path="js.Promise"><c path="ofJsPromise.A"/></c></icast>
...
</from>
...
</abstract>
The same goes for Promise
btw.
The fun part is that dox
doesn't even process the implicit casts, see Any
. I'm inclined to say that how haxe.rtti
determines "mergeability" of abstracts based on implicit casts is flawed. Let's ask @Simn, @Gama11 and @markknol what their take is on that ;)
If the xml is wrong then its a Haxe issue, otherwise it's one for dox.
Can you see if Any in the xml contains this implicit data?
There is no problem with the treatment of Any
. My point was rather that implicit casts were apparently never added to the dox templates, which is ironic because they are what the rtti parser is choking on. The question here is: should the js version and the flash version of tink.core.Future
be considered incompatible because of an implicit cast or not. If so I'll probably have to pull some #if xml
trickery or what not.
Is there a workaround for this? I tried adding -ex "^tink\."
to dox
but still get the "Incompatibilities.." error
I'm inclined to say that this is a Haxe issue: https://github.com/HaxeFoundation/haxe/issues/7829
tink.core.Future
definition brokes hexMachina API generation: https://travis-ci.org/DoclerLabs/hexMachina/jobs/373031409Any idea how to fix that?