[typer] Delay typer creation to after init macros

[kLabz]

Following #11043, this PR turns the warnings (previously only enabled with -D haxe-next) into errors and actually delay the typer creation to after init macros.

This avoids ending up with more typing contexts than needed, which were leading to some nasty errors (including some infamous "type X is redefined from X" ones). This happened because init macros (or even other macros without the macro API separation) could change the context signature by altering defines.

A follow up will be needed, to ensure 4.3_bugfix displays warnings for all macro API that this PR covers (a few more than in previous PR) when using -D haxe-next.

I think this closes #7871 ?

[Simn]

I think we should factor out some of the "harmless" changes here, like the stuff that gets moved around and such. That way we can merge that immediately and then look into the actual delay change, which I expect to break a few things.

[kLabz]

I'm not sure much would break; I expect much more issues with the macro API restrictions, but that's expected and will have to be fixed on user/libs side for Haxe 5 anyway.

I will still separate in two PRs, if only to make review easier.

---

Hmm, moving com.global_metadata around without the typer delaying will apply @:build added by addGlobalMetadata to types in macro context too.. unfortunate 😖

Guess I'll have to remove that change from the preparation branch then.

[kLabz]

Rebased delay_typer_preparation (#11324) and set it as base for this PR to reduce the diff.
Will set the base back to development when #11324 is merged.

[kLabz]

@SomeRanDev could you try this branch with some reflaxe target to check if I didn't break it?

There are builds available on build.haxe.org:

• linux
• mac
• win64
• win32

[SomeRanDev]

No problem! Thanks for the build links! 👍

Unfortunately, I have encountered an issue. As far as I can tell, it's NOT from this branch, rather it was introduced from the custom target pr a couple months back (happens with every development build since then).

I'm a little embarrassed I didn't notice this until now, here's how it happens:

---

Minimal example project: unsupported_error.zip

Uncaught exception unsupported
[CALLSTACK] : Called from here

If the early __.Init.init() call is made, it causes some Compiler functions to trigger the above error. This happens even after the init macro phase.

I'm sure there's more, but the two I found were:

• haxe.macro.Compiler.addMetadata
• haxe.macro.ClassField.expr() will cause this even if the ClassField is discovered in the "Context.onAfterTyping" callback

Note the Init.init() function can be completely blank and this issue still occurs. If the Init module is renamed or deleted, everything works again.

It seems like the incomplete macro api is making it past the init macro phase?

[kLabz]

Thanks!
Indeed custom target init macro context was not cached (and thus not updated later with enhanced macro API). Provided example project now works.

New build:

• linux
• mac
• win64
• win32

[Simn]

Although it's unlikely to break again, it would be good to add a test for that exact situation.

[kLabz]

Yeah, was planning to do that; along with (testing) other things that could be broken with custom targets.

[SomeRanDev]

Sorry for the delay! Tried a bunch of different reflaxe and platform configs and nothing seemed to break or look weird, so looking good for me.👌