>> It should just be implied by -unittest!

+1


On Wed, Oct 26, 2016 at 7:49 AM, Nick Sabalausky via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:
>
>> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>>
>>> What would be possible is a "-fdmain" switch (force dummy main).
>>>
>>
>> It should just be implied by -unittest!
>>
>> The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway.
>>
>> Otherwise, let's make the default sane.
>>
>
> +1
>

On Wednesday, 26 October 2016 at 16:08:23 UTC, Sönke Ludwig wrote:
> How would a custom unit test runner such as "unit-threaded" or "tested" work in that case?

http://dpldocs.info/experimental-docs/core.runtime.Runtime.moduleUnitTester.1.html

http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester

Am 26.10.2016 um 18:32 schrieb Adam D. Ruppe:
> On Wednesday, 26 October 2016 at 16:08:23 UTC, Sönke Ludwig wrote:
>> How would a custom unit test runner such as "unit-threaded" or
>> "tested" work in that case?
>
> http://dpldocs.info/experimental-docs/core.runtime.Runtime.moduleUnitTester.1.html
>
>
> http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester

Thanks, that should work! I misremembered this as getting called once per module, which would have been insufficient.

On Wednesday, 26 October 2016 at 17:47:51 UTC, Sönke Ludwig wrote:
> I misremembered this as getting called once per module, which would have been insufficient.

Yeah, I don't love the name either.

But you should be able to set that in a static module ctor in your library (bonus points, even compare the old against the default and have a runtime warning about combining two incompatible test libraries) then go nuts with it.

I think currently the ModuleInfo unittests property combines all of them into a single function, so to get more granularity, you have to do CT reflection, which means listing all the modules... which kinda sucks right now.

It might be nice some day to make that easier. Separate out the runtime thing to return function array instead of one combined function, and perhaps some kind of assistance in walking the whole program import graph.

Regardless, unittests without main() should be perfectly doable today!

Am 26.10.2016 um 19:58 schrieb Adam D. Ruppe:
> On Wednesday, 26 October 2016 at 17:47:51 UTC, Sönke Ludwig wrote:
>> I misremembered this as getting called once per module, which would
>> have been insufficient.
>
> Yeah, I don't love the name either.
>
> But you should be able to set that in a static module ctor in your
> library (bonus points, even compare the old against the default and have
> a runtime warning about combining two incompatible test libraries) then
> go nuts with it.
>
> I think currently the ModuleInfo unittests property combines all of them
> into a single function, so to get more granularity, you have to do CT
> reflection, which means listing all the modules... which kinda sucks
> right now.
>
> It might be nice some day to make that easier. Separate out the runtime
> thing to return function array instead of one combined function, and
> perhaps some kind of assistance in walking the whole program import graph.
>
> Regardless, unittests without main() should be perfectly doable today!

Yeah, for being able to enumerate the modules, DUB in fact generates a special module if a custom unit test runner is used (well, actually it is currently tied to the "tested" runner for historic reasons, which should really be changed).

On Wednesday, 26 October 2016 at 16:12:26 UTC, Timothee Cour wrote:
>>> It should just be implied by -unittest!
>
> +1
>
>
> On Wed, Oct 26, 2016 at 7:49 AM, Nick Sabalausky via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:
>>
>>> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>>>
>>>> What would be possible is a "-fdmain" switch (force dummy main).
>>>>
>>>
>>> It should just be implied by -unittest!
>>>
>>> The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway.
>>>
>>> Otherwise, let's make the default sane.
>>>
>>
>> +1

It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful):

1. deactivate the main functionDeclaration un funcs.d

....
final bool isMain()
{
   return ident == Id.main && linkage != LINKc && !isMember() && !isNested()
    && !global.params.useUnitTests;
}
...

2. forces -main in params.d:

...
else if (strcmp(p + 1, "unittest") == 0)
{
    global.params.useUnitTests = true;
    global.params.addMain = true;
}
...

I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR.

Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.

On 10/26/16 1:24 AM, deadalnix wrote:
> Seriously that makes no sense, almost everybody has it own hack to have
> a different main when building for unitests, and we look like clown.
>
> We all like to talk about language feature and all, but seriously, this
> kind of thing is what hurts us the most. We kind of live with it because
> we all have our workaround here, but really, it looks stupid to anyone
> that don't the tricks, and really, it should looks silly to anyone that
> knows the trick.
>
> Can I have my unittest build do not complain if there is no main and not
> run main ?
>

I'm with you 100%. This isn't even that hard, and doesn't require DMD changes. The runtime can exit if it runs any unit tests before calling main.

-Steve

On 10/27/16 9:09 AM, Steven Schveighoffer wrote:
> On 10/26/16 1:24 AM, deadalnix wrote:
>> Seriously that makes no sense, almost everybody has it own hack to have
>> a different main when building for unitests, and we look like clown.
>>
>> We all like to talk about language feature and all, but seriously, this
>> kind of thing is what hurts us the most. We kind of live with it because
>> we all have our workaround here, but really, it looks stupid to anyone
>> that don't the tricks, and really, it should looks silly to anyone that
>> knows the trick.
>>
>> Can I have my unittest build do not complain if there is no main and not
>> run main ?
>>
>
> I'm with you 100%. This isn't even that hard, and doesn't require DMD
> changes. The runtime can exit if it runs any unit tests before calling
> main.

This was pretty easy, please review/comment:

https://github.com/dlang/druntime/pull/1685

-Steve

On Wednesday, 26 October 2016 at 21:57:59 UTC, Basile B. wrote:
> It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful):
>
> 1. deactivate the main functionDeclaration un funcs.d
>
> ....
> final bool isMain()
> {
>    return ident == Id.main && linkage != LINKc && !isMember() && !isNested()
>     && !global.params.useUnitTests;
> }
> ...
>
> 2. forces -main in params.d:
>
> ...
> else if (strcmp(p + 1, "unittest") == 0)
> {
>     global.params.useUnitTests = true;
>     global.params.addMain = true;
> }
> ...
>
> I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR.
>
> Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.

I tried that and it doesn't work. addMain actualy just inject a main function as a mixin in the module. Yes this is a string, it is parsed and all.

The problem is that this function that is injected is then not wired in as main, because isMain returns false.

Any tips appreciated.

On Friday, 18 November 2016 at 07:51:35 UTC, deadalnix wrote:
> On Wednesday, 26 October 2016 at 21:57:59 UTC, Basile B. wrote:
>> It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful):
>>
>> 1. deactivate the main functionDeclaration un funcs.d
>> [...]
>> 2. forces -main in params.d:
>> [...]
>> I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR.
>>
>> Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.
>
> I tried that and it doesn't work. addMain actualy just inject a main function as a mixin in the module. Yes this is a string, it is parsed and all.

Sorry to learn that. To be honest I didn't try. For now and since three or four months I use an IDE solution. It detects the main() function and sets the -main switch accordingly. Anyway I would prefer something similar directly in the compiler.

> The problem is that this function that is injected is then not wired in as main, because isMain returns false.
>
> Any tips appreciated.