Is it possible to run the unittests of a module with -betterC like

    dmd -D -g -main -unittest -betterC f.d

?

This currently errors as

/usr/include/dmd/druntime/import/core/internal/entrypoint.d:34: error: undefined reference to '_d_run_main'

for an empty file f.d

On Mon, Oct 28, 2019 at 9:40 AM Per Nordlöw via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>
> Is it possible to run the unittests of a module with -betterC like
>
>      dmd -D -g -main -unittest -betterC f.d
>
> ?
>
> This currently errors as
>
> /usr/include/dmd/druntime/import/core/internal/entrypoint.d:34: error: undefined reference to '_d_run_main'
>
> for an empty file f.d

AFAIK no,

https://dlang.org/spec/betterc.html#unittests

On Monday, 28 October 2019 at 08:51:02 UTC, Daniel Kozak wrote:
> On Mon, Oct 28, 2019 at 9:40 AM Per Nordlöw via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>>
>> Is it possible to run the unittests of a module with -betterC like
>>
>>      dmd -D -g -main -unittest -betterC f.d
>>
>> ?
>>
>> This currently errors as
>>
>> /usr/include/dmd/druntime/import/core/internal/entrypoint.d:34: error: undefined reference to '_d_run_main'
>>
>> for an empty file f.d
>
> AFAIK no,
>
> https://dlang.org/spec/betterc.html#unittests

-unittest sets the 'unittest' version identifier. So this works:

  unittest {
     assert(0);
  }

  version(unittest) {
      extern(C) void main() {
          static foreach(u; __traits(getUnitTests, __traits(parent, main)))
              u();
      }
  }

dmd -betterC -unittest -run module.d

On Tuesday, 29 October 2019 at 08:45:15 UTC, mipri wrote:
> [snip]
>
> -unittest sets the 'unittest' version identifier. So this works:
>
>   unittest {
>      assert(0);
>   }
>
>   version(unittest) {
>       extern(C) void main() {
>           static foreach(u; __traits(getUnitTests, __traits(parent, main)))
>               u();
>       }
>   }
>
> dmd -betterC -unittest -run module.d

I feel like this should be added into the compiler so that it just works.

On Wednesday, 30 October 2019 at 15:09:40 UTC, jmh530 wrote:
> [snip]
>
> I feel like this should be added into the compiler so that it just works.

Hmm, maybe only when compiled with -main, but I don't think there's a version for that.

On 2019-10-30 16:09, jmh530 wrote:

> I feel like this should be added into the compiler so that it just works.

This will only run the unit tests in the current modules. The standard way of running the unit tests will run the unit tests in all modules.

-- 
/Jacob Carlborg

On Wednesday, 30 October 2019 at 18:45:50 UTC, Jacob Carlborg wrote:
> On 2019-10-30 16:09, jmh530 wrote:
>
>> I feel like this should be added into the compiler so that it just works.
>
> This will only run the unit tests in the current modules. The standard way of running the unit tests will run the unit tests in all modules.

That's a fair point, but the broader point I was trying to make was that anything that makes unittests easier to use betterC code is a good thing.

It seems as if there are three underlying issues here that need to be addressed to improve the usefulness of unittests in betterC code: 1) a way to gather the unittests from all modules (your point), 2) fixing -main for betterC, 3) a way to ensure that said unittests are called.

The first suggests to me that it would not be such a bad thing to generate ModuleInfo when -unittest is called with -betterC or at least just the ModuleInfo needed to aggregate the unittests from different modules. This functionality might need to be opt-in.

The second is pretty obvious. dmd -main -betterC is inserting a D main function instead of a C one. I submitted a bug request
https://issues.dlang.org/show_bug.cgi?id=20340
as this should be pretty easy to fix.

The final point depends on the two above being resolved. If dmd -unittest -main -betterC is called, then the compiler would be creating the main function so it can insert any code needed to run the unittests (assuming issue 1 above is resolved). By contrast, if just dmd -unittest -betterC is called and the user has created their own main, then it would be like having to run a shared module constructor, which is disabled in betterC. Again, I would assume that the benefits would outweigh the costs in allowing something like this on an opt-in basis, but the available options would be to either a) use -main or b) create a mixin that generates the needed unittest code so that people can insert it at the top of their main function on their own.