Macro defined modules vs direct loading of types using it

[kLabz]

While this looks like a very edge case / weird usage, this actually is easy to trigger in real use case because of diagnostics triggering similar behavior to compile2.hxml.

Not sure yet how to handle that, just pushing the repro for now..

[kLabz]

@Simn any idea how this could be handled?

[Simn]

Could you describe the actual problem? I can't really make it out from looking at that test.

[kLabz]

Flushing between each actx.classes load seems to do the job, but will have to watch out for new issues..

Edit: only test failure detected so far:

Done running 664 tests with 1 failures
SUMMARY:
projects/Issue11004/build.hxml
-Bar.hx:27: @:storedTypedExpr 3 computed this_ident as: foo.bar
+Bar.hx:27: @:storedTypedExpr 1 computed this_ident as: foo.bar

Might not be a problem, but would need to double check there

[kLabz]

"Normal" typing order:

• Main
• foo.Foo
• => build macro, with defineType
• Baz
• => FooData is built

But when adding Baz to actx.classes, we get:

• Main
• foo.Foo
• no flush so no build macro run at this point
• Baz
• => FooData is not built yet

[Simn]

I can't immediately tell what the difference is between referencing Baz on the command line vs. referencing it from Main itself, e.g. via a typedef X = Baz at the bottom.

[kLabz]

Difference is each of those types referenced in command line / display files / main are loaded without flushing there:

haxe/src/compiler/compiler.ml

Line 311 in b537e99

List.iter (fun cpath -> ignore(tctx.Typecore.g.Typecore.do_load_module tctx cpath null_pos)) (List.rev actx.classes);

So build macros don't happen early enough

[kLabz]

vs. referencing it from Main itself, e.g. via a typedef X = Baz at the bottom.

This does trigger the issue too indeed

[Simn]

Flushing what exactly, and where does that normally occur?

[kLabz]

Flushing what exactly, and where does that normally occur?

Doing a flush_pass tctx.g PBuildClass in between those:

haxe/src/compiler/compiler.ml

Line 311 in b537e99

List.iter (fun cpath -> ignore(tctx.Typecore.g.Typecore.do_load_module tctx cpath null_pos)) (List.rev actx.classes);

[kLabz]

I found another way to trigger this issue in a shiro project, basically with haxe build.hxml ParentClass ChildClass (or Json RPC diagnostics with ParentClass.hx and ChildClass.hx open), resulting in:

Loop in class building prevent compiler termination (ParentClass)

I don't have a minimal repro yet to add as test; ideas would be appreciated 😅
(edit: flush does fix that too)

[kLabz]

@Simn can we merge this? It can happen easily with multi file diagnostics :/

[Simn]

It's unlikely to be a good fix because it doesn't address the typedef X = Baz case. We can merge it to get the test, but let's keep an issue open for the more general situation. Maybe even a PR that has a failing test case.

[kLabz]

Right. I don't know why I thought the typedef situation was expected

[kLabz]

This also somehow solves an issue I have with compiling some shiro projects (while others on windows don't have the issue), but I'm also getting some X is redefined from X errors which could be related to this PR... so uh might not be a good idea to merge yet.

Edit:

• Those errors are actually domkit vs Remove weird partial resolution #11338 issues
• X is redefined from X is not because of this PR.. I get it with development (before Remove weird partial resolution #11338) too