[hlc] disable dump_types by default

[yuxiaomao]

We found that the function dump_types introduced in https://github.com/HaxeFoundation/haxe/commit/9dcb694 makes the compilation very long on clang++ for a console target. This PR disable dump_types by default by a #ifdef and show a runtime error if the dump function is called.

[Simn]

Isn't it a bit strange to have this as a runtime-error? If the function isn't defined then I'd expect a C-level compiler error instead.

[yuxiaomao]

The goal is to be able to compile without the content of this function - clang++ on this console target takes additional 10 mins when building the file (hl/types.c) compared to when the function is not there, it's quite annoying during development. Additionally, the only function that uses dump_types() is hl_gc_dump_memory() which is a debug function, it does not need to be defined in most cases. So we don't want a compile time error.

However if we don't define dump_types(), the memory dump produced could not be interpreted due to lack of type information. For this reason we would like to produce a runtime error to warn the user who call the dump memory function, and give them the name of the define needed (as it is not documented and is generated during compilation, it's difficult to find out).

[Simn]

Looking at hl_gc_dump_memory, there's already a check for when the dump function isn't defined:

if( gc_types_dump ) gc_types_dump(fdump_d);

I still find it strange to define it and register it via hl_gc_set_dump_types(dump_types) only to then have it error at runtime. I'd instead expect the entire function to not exist (and not be registered) at all, because then you can at least still use the rest of hl_gc_dump_memory.

If discoverability is a concern then you could just make that function print a note about defining HL_DUMP_TYPES instead.

[yuxiaomao]

So if we really need discoverability, you would suggest let hl_gc_dump_memory detect if( !gc_types_dump ) and print HL_DUMP_TYPES ? Or let dump_types only print error and do not throw error ? I also think it's a little bit strange to register and print only runtime error, but my concern is that this is only valid for HL/C and will requires a specific haxe version, which could lead to some confusion if the message is print but the define does not exists.

[Simn]

So if we really need discoverability, you would suggest let hl_gc_dump_memory detect if( !gc_types_dump ) and print HL_DUMP_TYPES ? Or let dump_types only print error and do not throw error ?

Both sound good to me.

I also think it's a little bit strange to register and print only runtime error, but my concern is that this is only valid for HL/C and will requires a specific haxe version, which could lead to some confusion if the message is print but the define does not exists.

Well, if the define doesn't exist then there's no problem because the function is currently always registered. The only potentially confusing situation is when the HL runtime is used without Haxe, but that's an entirely different conversation.

[yuxiaomao]

I think I prefer print in Haxe so the define and info print are at the same place. And print is probably more gentle compared to error in a gc locked context.

[Simn]

IMO this shouldn't be phrased like an error in the first place, but I don't really mind.

[Simn]

Thank you for your patience!