ModuleInfo, factories, and unittesting

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 06:18 AM, Atila Neves wrote:
> On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:
>> On 12/22/2016 12:46 PM, Piotrek wrote:
>>> The inability to give test a name (plus selective unittesting) and
>>> continue on failure is puzzling to me.
>>
>> Both of these are affordable with the current language (attributes)
>> with changes to druntime. Who wants to take this? -- Andrei
>
> I would, but I don't see how this is possible without one of:
>
> 1) A standardised build system
> 2) Changes to the language
>
> Attributes mean static reflection, and that means explicitly (and at
> compile-time) stating every module being built somewhere. There is no
> current way to reflect on packages.

Oh, I see. So there needs to be some sort of cooperation between the 
compile-time realm (stash the unittest attributes during compilation) 
and the run-time realm (pick up that data and use it).

> The only way I know how to do this
> is to use the build system to autogenerate a D file listing all modules
> to reflect on, which not coincidentally is how unit-threaded does it,
> with dub. But it only works if you're using dub and even then fails
> sometimes if it can't parse `dub describe` properly.

Got it.

> I would've changed druntime 4 years ago if I could, it's the only reason
> I know of ModuleInfo and what it has to do with unit tests.
>
> Maybe I'm missing something or lacking imagination.

Well clearly some changes in the compiler and/or runtime could bring us 
to where we want to be.


Andrei