Should not parse statements inside macros or if it does should render all of them and info about the macro its inner references

[cancerberoSgx]

May be related to #241

The tool parses statements inside macros. I don't know if this only happen for typedef or for "alias of" but it should never do it. So please check if the issue is not happening in other places. Then this tool by default should never consider statements inside macros unless user explicitly configures it. Otherwise, if it does, then it should print all of them no matter if repeated and and also information about the macro applied (and references to names used by the macro too).

Because of this issue, https://api.haxe.org/haxe/io/BytesData.html API docs are incorrect and confusing since it says BytesData is an alias of https://api.haxe.org/flash/utils/ByteArray.html which is a flash only class. It's not an alias of anything and what's happening is that dox parses a statement inside a macro -there are several like it but it takes only the first which is flash's

if a statement is inside a macro and user want's to document that, then it should be its responsibility to somehow instruct the tool, for example, creating a dummy expression just for documentation, or perhaps specially flagin the statement inside the macro so the tool parse it.

Other wise if parsing things inside macros, it should parse all statement no matter if they are identical and show them all and also information regarding which macro are applied to each - not just the first one.

in this particular case, this really confuse people since:

• BytesData (as many other core names) have not familiar names in standard platforms like POSIX as, in general, other languages do for core things like IO since low level types often needs to be perfectly understood by users
• BytesData it doesn't have any documentation and no members so there is no relevant information but the link to an incorrect type

This could make newcomers waste lots of time if trying to use what the documentation specify and confusion while trying to understand the API as a whole since it's not easy / common to realize that is an error in the api documentation.

From a new user like me it doesn't give a good image of the platform that, besides not having descriptions of any core class, it has miss leading links like this.

I wonder who decided to name core things things with unfamiliar names and was not responsible to document at least a basic description of types. These are core types for all targets !! :(

This platform could have much more success if it has descent documentation. Is too late to change the creative names but not for writing some docs. Unfortunately it is too late to give the examples to their library author users that, the few that exists have no apidocs, no readme and no examples at all - :( Is not serious and not friendly to people that comes from other platforms and even more seen so few issues in haxe repo complaining about this.
Thanks

[Gama11]

Dox doesn't parse anything. The Haxe compiler does the parsing, and dox consumes its XML output.

[cancerberoSgx]

aja , I'm new here but want to help if I can. Will try to see how to generate that XML that I suppose is something like the code's AST, in the meanwhile do you know if contains information about macros wrapping expressions ? If it has the information available, then, again is dox responsibility. Sorry for the confusion, thanks

[Gama11]

Turns out dox has enough info to render it like this, which is pretty neat. :)