Bug 17035 – extern(C) and extern(C++) module ctor/dtor should behave like the C init/fini functions

If a module ctor is declared as: extern(C) static shared this() {} or extern(C++) static shared this() {} then it should follow the C/C++ convention of library initialization: no circularity checking, no guaranteed order of execution, no guarantee the GC is initialized etc. The way this is done on Linux is by placing pointers to these functions in a segment called "init_array". Similarly, if a module dtor is declared as: extern(C) static shared ~this() {} or extern(C++) static shared ~this() {} then it should follow the same regime as C++ static destructors. On Linux pointers to these functions are placed in a segment called "fini_array". For reference see gcc's __attribute__((constructor)), __attribute__((destructor)). This should make it easier to write library initialization code that does not depend on druntime.

LDC has been supporting this for a while with a compiler-specific pragma: https://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor Tying this to extern(C)/extern(C++) might look nicer syntactically, although I'm not sure about conflating what usually concerns ABI (in the wider sense) with runtime behaviour. Either way, since it is quite a sharp tool (no guarantees about runtime/GC initialisation), we should make sure to handle deprecation properly – "extern(C):" and "shared static this" (order!) might already be used in the same file and would change meaning.

This please! I've just run into a case of this.

We now have `pragma(crt_constructor)` and `pragma(crt_destructor)`, which cover this use case. So the feature is here, just with a different syntax. Marking as duplicate of the issue that was fixed (although it was filed 1 year after). *** This issue has been marked as a duplicate of issue 17868 ***