• Per =?UTF-8?B?Tm9yZGzDtnc=?= (7/7) Oct 28 2019 Is it possible to run the unittests of a module with -betterC like
• Daniel Kozak (4/11) Oct 28 2019 AFAIK no,
• mipri (13/30) Oct 29 2019 -unittest sets the 'unittest' version identifier. So this works:
• jmh530 (3/16) Oct 30 2019 I feel like this should be added into the compiler so that it
• jmh530 (3/6) Oct 30 2019 Hmm, maybe only when compiled with -main, but I don't think
• Jacob Carlborg (5/6) Oct 30 2019 This will only run the unit tests in the current modules. The standard
• jmh530 (30/36) Oct 30 2019 That's a fair point, but the broader point I was trying to make

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

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

Daniel Kozak <kozzi11 gmail.com> writes:

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

mipri <mipri minimaltype.com> writes:

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

jmh530 <john.michael.hall gmail.com> writes:

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.

jmh530 <john.michael.hall gmail.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

jmh530 <john.michael.hall gmail.com> writes:

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.