Class build loop detection breaks everything.

[back2dos]

I get this error a lot: acaa3ec#diff-4a35a028da1fe67ee6a21fbd5305d08cR3127

Minimal example (save as WindowManager.hx and compile with haxe -lib coconut.vdom WindowManager -js whatever.js):

package ;

import coconut.ui.*;
import coconut.data.*;
using tink.CoreApi;

class DefaultWindowManager extends View<{}> {
  function render() '<div />';
}

class Window extends View<{}> {
  function render() '<div />';
}

There is nothing cyclic going on anywhere, so I wonder if the detection logic itself is flawed/based on assumptions that I break. My guess is that the issue could be caused by the fact that there's two build macros, one being @:autoBuild on coconut.ui.View and one being a global one (per --macro addGlobalMetadata) from tink_syntaxhub.

FWIW this code (well actually, the whole project, which is far more complex) certainly did not prevent the compiler from terminating, so I have to wonder what's wrong here.

[ncannasse]

To get an idea about what's happening you can remove the (*/* and */*) comments in typecore.ml to enable the debug section, then compile with -D cdebug to get a trace of all compiler process

[ncannasse]

If you don't want to change the compiler, try sending a minimal reproducible example without any library involved

[nadako]

This seems to be a case of follow-when-building, I reduced the example to this:

Main.hx

@:build(Macro.build())
class BuiltBase {}

class Base extends BuiltBase {}

class A extends Base {}

class B extends Base {}

VDom.hx

class VDom {
	static function f() new HtmlFragment();
}

HtmlFragment .hx

class HtmlFragment {
	public function new() {}
}

Macro.hx

#if macro
import haxe.macro.Context;

class Macro {
	static function build() {
		switch Context.getType("VDom") {
			case TInst(_.get() => cl, _):
				for (f in cl.statics.get())
					Context.follow(f.type);
			case _:
		}
		return [];
	}
}
#end

[Simn]

Sanitized cdebug for that:

  out 0 add build-module ()
  out 0 add force (StdTypes)
  out 0 add build-class (StdTypes)
  out 0 add build-class (String)
  out 0 add build-class (Array)
  out 0 add build-class (haxe.EnumTools)
  out 0 add build-class (Std)
  out 0 add build-class (Main)
  out 0 flush final(final)
  out 1 	run build-module ()
  out 1 	run build-module ()
  out 1 	run build-class (Main.B)
  out 2 		run build-class (Main.Base)
  out 3 			run build-class (Main.BuiltBase)
  out 4 				add build-class (VDom)
  out 4 				run build-class (VDom)
  out 5 					init_class_done VDom
  out 5 					add type-field (VDom:f)
  out 4 				run type_fun (VDom:f) ??PENDING[build-class (VDom);build-class (Main);build-class (Main);build-class (Main);build-class (Std);build-class (haxe.EnumTools);build-class (haxe.EnumTools);build-class (Array);build-class (String);build-class (StdTypes)]
  out 5 					add build-class (HtmlFragment)
  out 5 					flush build-class(load_module)
  out 6 						run build-class (HtmlFragment)
  out 7 							init_class_done HtmlFragment
  out 7 							add type-field (HtmlFragment:new)
  out 6 						run build-class (Main.A)
  out 7 							add late build-class (Main)
  out 6 						run build-class (Std)
  out 6 						run build-class (haxe.EnumTools.EnumValueTools)
  out 6 						run build-class (haxe.EnumTools)
  out 6 						run build-class (Array)
  out 6 						run build-class (String)
  out 6 						run build-class (StdTypes.ArrayAccess)
  out 6 						run build-module (Main)
  out 7 							add late build-class (Main)
  out 6 						run build-module (Main)
  out 7 							FATAL Error.Error(_, _)

[ncannasse]

I'm not sure what do to with this.

Trying to type things while in a build macro is unsound.

Depending on the things being currently on the typing stack (in our case build Main.Base) we might enter an infinite loop which is what happens here.

This is because typing requires all classes to be built. Typing without it if we want to turn the whole thing into a lazy process would require to perform a cl_build() everytime we access a TInst class value in the whole compiler code...

Now it's true that before we might have let things error silently so if you were lucky you didn't hit into a problem, but that does not mean it was correctly working.

@back2dos do you perform / trigger typing in your example ? What's the basis for it ?

[ncannasse]

The problem comes from subclasses with build macro. We require before entering typing that all classes are built, but we can't built the subclasses because we are currently building the superclass.

An approach would be to ignore such cases, but then that would require to store theses "skipped builds" somewhere and put them back into the task list after we have finished building the superclass so they don't get skipped (which would cause problems later)

[back2dos]

Stupid question: why exactly does the typing of Main.B involve the typing of Main.A?

Because as it is, there is nothing cyclic in the code. It's not like the build macro of B triggers building of A which then goes to access the fields of B or something. Otherwise put: shouldn't out 6 run build-class (Main.A) be out 1 run build-class (Main.A)?

[ncannasse]

It's not about cycle. Before entering expression typing we need to make sure that all pending classes structure are correctly populated, so we need to build all of them, because we will not check/trigger such build everytime we access the class structure/fields

[Simn]

What if we had something like this:

and tclass_structure = {
	mutable cl_fields : (string, tclass_field) PMap.t;
	mutable cl_statics : (string, tclass_field) PMap.t;
	mutable cl_ordered_statics : tclass_field list;
	mutable cl_ordered_fields : tclass_field list;
}

and tclass = {
	mutable cl_structure : unit -> tclass_structure;
}

And then the cl_structure function calls cl_build()?

[Simn]

I guess cl_constructor would have to go in there too...

[ncannasse]

That is not an easy change.

…

On Tue, Sep 26, 2017 at 10:05 AM, Simon Krajewski ***@***.***> wrote: I guess cl_constructor would have to go in there too... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6567 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwDelRtc5jYPal26ICPZzSwSMFrn8ks5smLBjgaJpZM4PRVUO> .

[Simn]

You're not lying...

[back2dos]

Generally, having the build of one class depend on the structure of another is very useful. It's what syntactic delegation works in tink_lang. And it's how one would have to implement something like haxe.remoting.Proxy per macro.

But: in all of these use cases, one doesn't need "the full information". Would it be any easier if we said that getting the fields doesn't require to start expression typing? I think one really only needs to know that the field is a TFun and the number, names and optionality of the arguments. All the argument types and the return type could just be TLazy and the compiler can do something about that in a later pass. Just an uninformed guess ;)