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.
