Fix windows debug build

[marler8997]

Windows debug build is currently broken because dmd does not generate the 'main' function. I bisected the cause to this commit (fed25ec). It looks like the main method was removed in the -unittest build which explains what happened. I've removed that change so that the main method still exists in a unittest build. I'm not sure why main was removed in the first place, maybe there was a reason so if there was please chime in let me know if another kind of change is needed here.

[dlang-bot]

Thanks for your pull request, @marler8997! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[wilzbach]

I'm not sure why main was removed in the first place, maybe there was a reason so if there was please chime in let me know if another kind of change is needed here.

The main method can't be part of the dmd unittest executable. This is a well-known limitation of D's unittest, but luckily this will be fixed in 2.080. The correct fix is to remove -unittest from the DDEBUG flags in win32.mak:

dmd/src/win32.mak

Line 135 in 7c888c4

DDEBUG=-debug -g -unittest

After #6767, I actually tried to add a similar target to win32.mak, but I'm still fighting with the auto-tester / Windows build setup: #7414

[marler8997]

So that means you cannot compile in unittests into your dmd executable on windows, you have to make a seperate exe for your unittests. I've updated this PR with another change that "works around" this issue of not being able to include the main in "mars.d" without preventing a user from being able to include unittests in the main build.

[wilzbach]

preventing a user from being able to include unittests in the main build.

Why would you want to run all unittest whenever you call the DMD executable? What's the use case?
The already existing target unittest for Windows will be "fixed" soon -> #7414

[marler8997]

So I don't have to build dmd twice when I'm in development.

[marler8997]

Come to think of it, a nice feature for dmd would be to build in unittests, but have a way to turn them on and off whenever your run your exe.

[wilzbach]

So I don't have to build dmd twice when I'm in development.

That's quite a atypical way to do debugging (at least for a Linux dev) 😱
Is this really the way people use the debug mode on Windows?
CC @rainers

FWIW if you intend to use this strategy, you will need to pass --DRT-testmode=run-main or add a custom ModuleUnitTester soon:

1. "run-main": even if unit tests are run (and all pass), main is still run.
    This is currently the default.
2. "test-or-main": any unit tests present will cause the program to
    summarize the results and exit regardless of the result. This will be the
    default in 2.080.

Come to think of it, a nice feature for dmd would be to build in unittests, but have a way to turn them on and off whenever your run your exe.

--DRT-testmode=run-main and --DRT-testmode=test-only (there's no main-only)

[marler8997]

There's pros and cons to each method. In any case, if you can support both use cases why wouldn't you? If a developer wants to add the "-unittest" flag to their DEBUG build, the current code would cause a very cryptic set of linker errors. This of course should be solved by fixing the linker but it's been that way forever with no solution in sight.

Those druntime options look real nice, adding a main-only seems to be the ticket :) You could also modify dmd to change the default to main-only which would be perfect for my use case.

NoMain seems to be an compromise between both worlds.

[marler8997]

With the current code you get the following

-unittest # doesn't work, and you get a bunch of cryptic linker errors
-unittest -main # works, seems counter intuitive that this works for a program that already has a main

With this PR you get this

-unittest # works
-unittest -main # doesn't work, you'll get an error saying you can't have multiple mains

The second set of options is more intuitive. Then if the developer realizes they need to disable "main" from mars.d, they'll browse to the code so they can "comment it out" and see there is already a version(NoMain) and realize they can just add the -version=NoMain option.

[rainers]

That's quite a atypical way to do debugging (at least for a Linux dev) 😱
Is this really the way people use the debug mode on Windows?
CC @rainers

I don't think there are Windows specific approaches to testing. Building both test and main into the same excutable and running them both is just the (rather unconventional) way that has been more or less enforced by dmd for years.

[wilzbach]

I'm sorry for breaking your workflow. I didn't really consider that people might be abusing the -unittest feature. As mentioned above, you won't be able to use this approach after 2.080 without modifications, but that's a battle for a different day and I still have hopes that until then you will realize the advantages of having a separate test executable ;-)
Also we will hopefully get more and more unittest blocks within the DMD codebase, because it's now a proper Makefile target on Posix and actively checked by the auto-tester, but sticking with the status quo and using the NoMain versioning sounds reasonable and should as you said please everyone.

[wilzbach]

Building both test and main into the same excutable and running them both is just the (rather unconventional) way that has been more or less enforced by dmd for years.

So people under Windows currently don't/can't build a DMD executable with debug symbols and without unittests under Windows?

[CyberShadow]

I think the idea behind the initial design of -unittest was to allow the program to perform an internal self-test before running the main function. That doesn't align with modern TDD practices, where unit tests are ran before committing or on a CI system, but that doesn't make it an invalid idea. I wouldn't be surprised if the change caused more people to complain.

[marler8997]

So people under Windows currently don't/can't build a DMD executable with debug symbols and without unittests under Windows?

I think he was just saying that by default, the debug build also includes unittests. There's no reason a developer couldn't remove that flag in the makefile.

...As mentioned above, you won't be able to use this approach after 2.080 without modifications,..

I'm not familiar with the change coming in to 2.080, are we changing the semantics of the -unittest flag?

[wilzbach]

I think he was just saying that by default, the debug build also includes unittests. There's no reason a developer couldn't remove that flag in the makefile.

Yes of course, but I was asking out-of-the-box? Needing to modify the Makefile isn't a good practice.

I'm not familiar with the change coming in to 2.080, are we changing the semantics of the -unittest flag?

Well, the default behavior of how -unittest and the main method interact will be fixed!
See also: dlang/druntime#1685 (the same PR which introduced --DRT-testmode=test-only)