ModuleInfo, factories, and unittesting

[Johannes Pfau via Digitalmars-d]

Am Tue, 20 Dec 2016 12:36:53 -0800
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 12/20/2016 11:05 AM, Dicebot wrote:
> > Yes, pretty much. What ways do you have in mind? I am only aware of
> > two:
> >
> > 1) ModuleInfo
> > 2) https://dlang.org/spec/traits.html#getUnitTests  
> 
> 
> Put pointers to them in a special segment.

You need some kind of linker support to do this to provide the
start/end symbols. Binutils has got a nice feature to do that
automatically for you though:
https://sourceware.org/binutils/docs/ld/Orphan-Sections.html

" If an orphaned section's name is representable as a C identifier then
the linker will automatically see PROVIDE two symbols: __start_SECNAME
and __stop_SECNAME, where SECNAME is the name of the section."


However, things get a little more complicated when shared libraries are
involved. You'll have to make the __start/__stop symbols private to the
library (that's easy) and somehow provide a function in every library
to access the library private __start/__stop symbols. That's basically
how we assemble the list of moduleinfos in rt.sections.



Back to topic: I'd really love to see a generalization of RTInfo/mixin
templates in D:
----------------------------------------------------------------------
@auto mixin template scanUnittests(Module)
{
    static if (hasUnittest!Module)
    {
        static this()
        {
            foreach(test, getUnittests!Module)
                test();
        }
    }
}
----------------------------------------------------------------------

Whenever you import a module containing an @auto mixin the compiler
would mixin the declaration into the module. This should be
incredibly powerful for serialization, std.benchmark and all kind of
introspection tasks. (You then still need some way to pass this
information to the 'runtime' world. Either static this, C-style ctors
or custom data sections are possibilities. OTOH a mixin can also define
members that are accessible from the outside if the module name is
known)