[Issue 10023] Add rtInfo (or equivalent) to ModuleInfo

December 24, 2016
Posted by Johannes Pfau
Permalink
Johannes Pfau
Permalink
https://issues.dlang.org/show_bug.cgi?id=10023

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau@gmail.com

--- Comment #6 from Johannes Pfau <johannespfau@gmail.com> ---
> We are still lacking a workable idea how to make RTInfo/RMInfo customizable.

Just some thoughts:

As there are currently discussions of dropping ModuleInfo completely what we really need is some way to aggregate information from different modules where the modules are not necessarily known during compilation. And the kind of information that is aggregated is user defined.

So issue 1: Aggregating information from different modules (with full support for separate compilation, shared libraries, dlopened libraries)

1)
The most portable way to implement this is using small C constructor stubs.
There's not much backend magic required to enable this:

@clikeCtor void registerData()
{
    import baseModule;
    baseModule.register(...);
}

Such functions are implemented as __attribute__((constructor)) functions. There is some runtime overhead involved, but the code can be adapted to any usecase. Things get a little more complicated if you want to aggregate data per library, e.g. you might want to have a list of all Webpage subclasses in a dlopened shared library. In that case the aggregation code could use per-library hidden fields and access the data using library-exported accessor functions.


2)
Without runtime overhead, but needs some kind of linker support: Aggregate
symbols into a custom section. Use per library start/end markers to guard the
section and provide per library accessor functions to access the data.


Issue 2: Making sure every module A can add information related to module B.

My proposal is to introduce a special kind of mixin templates. Every module keeps a list of these special templates in the module and as soon as the module is imported all special 'auto mixin' templates are mixed into the importing module. A full reimplementation of the unittest system without ModuleInfo could then look like this:

------------------------------------------------------------------
module myunittest;

struct MyUnittest{}

@auto template mixin(Module)
{
    // 2 above
    @section("myunittest") TestModuleInfo info = getTests!Module;
    // alternatively 1 above
    @clikeCtor unittestConstructor()
    {
        registerTests(getTests!Module);
    }
}

void runTests()
{
    // approach 2
    TestModuleInfo[] tests = myunittest_start[0 .. myunittest_end - start];
    foreach(test; tests) ...
}
------------------------------------------------------------------

------------------------------------------------------------------
module user;
import myunittest;

@MyUnittest void testFunc1()
{
}
------------------------------------------------------------------

------------------------------------------------------------------
module main;
import myUnittest;

void main() {runTests()};
------------------------------------------------------------------

--
Forums
