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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10023

Johannes Pfau <johannespfau at gmail.com> changed:

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

--- Comment #6 from Johannes Pfau <johannespfau at 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()};
------------------------------------------------------------------

--