ModuleInfo, factories, and unittesting

[Nicholas Wilson via Digitalmars-d]

On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu 
wrote:
> Compulsive ModuleInfo generation seems to be a drag. I'm not 
> very familiar with the particulars but my understanding is 
> ModuleInfo is needed for (a) Object.factory and (b) finding and 
> running unittests.
>
> Walter and I think Object.factory was a mistake and we'd like 
> to make it opt-in long term (either by means of a build flag or 
> a class attribute).
>

Don't forget that typeinfos are classes too, which makes the 
class attribute approach less attractive.

> Until then, a very nice step forward is to NOT generate 
> ModuleInfo if a module introduces no class.
>

Module (static) ctors & dtors need MI.

> For unittests, I figure things like static introspection should 
> make it easier to enumerate and run unittests without a need 
> for ModuleInfo.
>

We have __traits(getUnitTests,...) but the way to do DIY 
unittests is
foreach(m; ModuleInfo)
     foreach(test; __traits(getUnitTests,m)
         test();

> What other issues/opportunities do you see related to 
> ModuleInfo?
>

AFAIK a module info is basically

struct ModuleInfo
{
     alias  F = void function();

     ModuleInfo* parent;
     string name; // may be static char array
     F s_ctor; // Static constructor
     F s_dtor;
     F ctor;    // Thread local constructor
     F dtor;
     F unittester; //may be an array for each block
     void function(Object)[string] factory_mapping; //Foward to 
argless ctor, not sure what mapping is actually used.
}

If we optionally remove Object.factory, and move the unittests 
elsewhere (where to?) we are left with the ctors and dtors. If we 
store these as SoA then we minimise space (as few modules define 
*tors), but lose the mapping from Module -> *tor, but these are 
defined to be run in an implementation defined order anyway so no 
big loss. This is only a problem when dealing with multiple 
libraries compiled separately and dynamic libraries, but if the 
dynamic libs store their own SoA'd *tors and we merge the static 
libs Arrays at link time** then we have nothing useful left in 
the module info.

If we could get factory_mapping mergeable at link-time then we 
would get a pay for what you use

** I don't know if this is possible, I don't mean merge duplicate 
symbols, I mean liba.a defines 3 module ctors, so does libb.a -> 
link == one ctor symbol 6 entries. Similar to what is done for 
C's global constructors, they end up in one big list.

>
> Thanks,
>
> Andrei