On 2016-12-18 17:53, 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).
>
> Until then, a very nice step forward is to NOT generate ModuleInfo if a
> module introduces no class.
>
> For unittests, I figure things like static introspection should make it
> easier to enumerate and run unittests without a need for ModuleInfo.
>
> What other issues/opportunities do you see related to ModuleInfo?

Looking in the compiler, I see references to:

* Coverage
* Asserts
* Arrays
* Objective-C class info. If this is not generated Objective-C class will not work

I'm not entirely sure what the above do.

-- 
/Jacob Carlborg

On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote:
> What other issues/opportunities do you see related to ModuleInfo?

IIRC TypeInfo is generated for C++ classes.

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).
>
> Until then, a very nice step forward is to NOT generate ModuleInfo if a module introduces no class.
>
> For unittests, I figure things like static introspection should make it easier to enumerate and run unittests without a need for ModuleInfo.

That is correct, and how unit-threaded works.

Atila

On Monday, 19 December 2016 at 00:00:36 UTC, Andrei Alexandrescu wrote:
> On 12/18/16 6:48 PM, Nicholas Wilson wrote:
>> On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote:
>>>[...]
>>
>> Don't forget that typeinfos are classes too, which makes the class
>> attribute approach less attractive.
>>
>>>[...]
>>
>> Module (static) ctors & dtors need MI.
>
> Cool cool cool. Thanks.
>
>>>[...]
>>
>> We have __traits(getUnitTests,...) but the way to do DIY unittests is
>> foreach(m; ModuleInfo)
>>     foreach(test; __traits(getUnitTests,m)
>>         test();
>
> Noice. Wait, the top foreach iterates what?

All the ModuleInfos in the binary. This confused the hell out of me when I was starting to learn D, since unit-threaded was my first project.

Atila

On Monday, 19 December 2016 at 00:15:24 UTC, Nicholas Wilson wrote:
> On Monday, 19 December 2016 at 00:00:36 UTC, Andrei Alexandrescu wrote:
>> On 12/18/16 6:48 PM, Nicholas Wilson wrote:
>>> [...]
>>
>> Cool cool cool. Thanks.
>>
>>>         [...]
>>
>> Noice. Wait, the top foreach iterates what?
>>
>
> Its a compile time magic loop I think. Both of them.

Nope, no magic. Just ModuleInfo.opApply in object.d.

Atila

On Monday, 19 December 2016 at 17:04:43 UTC, Atila Neves wrote:
> Nope, no magic. Just ModuleInfo.opApply in object.d.

Well, it is kinda magical because combining all the ModuleInfo takes some tricks from the linker. This method works with separate compilation, whereas the compile time tricks don't... and that's important to remember in any rewriting situations.

Looping over the modules, all of them, including from separately compiled libraries, is necessary for static ctors, dtors, tests, and other things. Any replacement needs to keep that in mind somehow.

The good news is we might be able to push it off onto the C runtime, if the order is done right. I'm not sure though.

On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote:
> On Monday, 19 December 2016 at 17:04:43 UTC, Atila Neves wrote:
>> Nope, no magic. Just ModuleInfo.opApply in object.d.
>
> Well, it is kinda magical because combining all the ModuleInfo takes some tricks from the linker. This method works with separate compilation, whereas the compile time tricks don't... and that's important to remember in any rewriting situations.

I'd forgotten about separate compilation. The issue there is the algorithm for naming unittest blocks gives different results depending on how the code is compiled, so __traits(getUnitTests) unfortunately currently only works with "compile all the things!". I'd forgotten I wanted to change the compiler code responsible for the naming.

Atila

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).
>
> Until then, a very nice step forward is to NOT generate ModuleInfo if a module introduces no class.
>
> For unittests, I figure things like static introspection should make it easier to enumerate and run unittests without a need for ModuleInfo.
>
> What other issues/opportunities do you see related to ModuleInfo?
>
>
> Thanks,
>
> Andrei

Factory without auto generated info is possible.
It needs works. Tried before:
https://github.com/dlang/phobos/pull/4062

On 12/19/16 1:25 PM, Basile B. wrote:
> 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).
>>
>> Until then, a very nice step forward is to NOT generate ModuleInfo if
>> a module introduces no class.
>>
>> For unittests, I figure things like static introspection should make
>> it easier to enumerate and run unittests without a need for ModuleInfo.
>>
>> What other issues/opportunities do you see related to ModuleInfo?
>>
>>
>> Thanks,
>>
>> Andrei
>
> Factory without auto generated info is possible.
> It needs works. Tried before:
> https://github.com/dlang/phobos/pull/4062

Thanks! -- Andrei

On 12/19/16 12:25 PM, Atila Neves wrote:
> On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote:
>> On Monday, 19 December 2016 at 17:04:43 UTC, Atila Neves wrote:
>>> Nope, no magic. Just ModuleInfo.opApply in object.d.
>>
>> Well, it is kinda magical because combining all the ModuleInfo takes
>> some tricks from the linker. This method works with separate
>> compilation, whereas the compile time tricks don't... and that's
>> important to remember in any rewriting situations.
>
> I'd forgotten about separate compilation. The issue there is the
> algorithm for naming unittest blocks gives different results depending
> on how the code is compiled, so __traits(getUnitTests) unfortunately
> currently only works with "compile all the things!". I'd forgotten I
> wanted to change the compiler code responsible for the naming.

Interesting, could you please add a detailed issue to bugzilla? Thanks! -- Andrei