Unittests require some mechanism to execute them.

Druntime provides this capability by default.

You can do it manually by using ``__traits(getUnitTests)`` to get access to the symbols.

Personally I just use full D for unittests.

On Sunday, 4 June 2023 at 20:43:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Unittests require some mechanism to execute them.
>
> Druntime provides this capability by default.
>
> You can do it manually by using ``__traits(getUnitTests)`` to get access to the symbols.
>
> Personally I just use full D for unittests.

Then this needs to be fixed asap, unittest needs to work for the flags user will use

D should not advertise broken features to the world with "deal with it" as workaround, this is not a new language, let's up out standard of quality

On 05/06/2023 9:20 AM, ryuukk_ wrote:
> Then this needs to be fixed asap, unittest needs to work for the flags user will use

There is nothing to fix.

You literally do not have any of the druntime code needed to handle ModuleInfo and hence call via it.

Nor do you have the entry point handled for you to call the functions...

This isn't a language only feature, its also a runtime feature. Just like module constructors are.

On Sunday, 4 June 2023 at 22:14:59 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 05/06/2023 9:20 AM, ryuukk_ wrote:
>> Then this needs to be fixed asap, unittest needs to work for the flags user will use
>
> There is nothing to fix.
>
> You literally do not have any of the druntime code needed to handle ModuleInfo and hence call via it.
>
> Nor do you have the entry point handled for you to call the functions...
>
> This isn't a language only feature, its also a runtime feature. Just like module constructors are.

I don't know how all this works, but the runtime shouldn't know about tests, imagine if you ship a game, and the player can run all the unittests, that doesn't make sense

The compiler should run the unittest, the compiler should run the unittest, no matter what flag the programmer is using, in that case: -betterC

If not, then it is a design flaw that needs to be fixed

You guys should read what you suggest to people sometimes, i repeat, D is not a new language, and D is not the only language, provide greatness to people, not dumb and broken stuff

Up your standard of quality

On 05/06/2023 3:42 PM, ryuukk_ wrote:
> I don't know how all this works, but the runtime shouldn't know about tests, imagine if you ship a game, and the player can run all the unittests, that doesn't make sense

Currently that is not possible. When you turn on unittests to be compiled in, that runtime will automatically run them and then end the program.

> The compiler should run the unittest, the compiler should run the unittest, no matter what flag the programmer is using, in that case: -betterC

Run what?

Until its in a binary on the target platform (which may not be the host), there is nothing to run.

Running using CTFE will not allow for testing for things that are platform dependent. Which we do plenty of.

> You guys should read what you suggest to people sometimes, i repeat, D is not a new language, and D is not the only language, provide greatness to people, not dumb and broken stuff

It's not broken. It's working exactly how it needs to work.

You can't expect a runtime dependent feature that has no way of working without a runtime, to work without a runtime.

On Monday, 5 June 2023 at 11:41:08 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 05/06/2023 3:42 PM, ryuukk_ wrote:
>> I don't know how all this works, but the runtime shouldn't know about tests, imagine if you ship a game, and the player can run all the unittests, that doesn't make sense
>
> Currently that is not possible. When you turn on unittests to be compiled in, that runtime will automatically run them and then end the program.
>
>> The compiler should run the unittest, the compiler should run the unittest, no matter what flag the programmer is using, in that case: -betterC
>
> Run what?
>
> Until its in a binary on the target platform (which may not be the host), there is nothing to run.
>
> Running using CTFE will not allow for testing for things that are platform dependent. Which we do plenty of.
>
>> You guys should read what you suggest to people sometimes, i repeat, D is not a new language, and D is not the only language, provide greatness to people, not dumb and broken stuff
>
> It's not broken. It's working exactly how it needs to work.
>
> You can't expect a runtime dependent feature that has no way of working without a runtime, to work without a runtime.

In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test

On 06/06/2023 2:16 AM, ryuukk_ wrote:
> In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test

If you as the user disable key components required for the language to fully work, its a you problem, not a compiler developer problem.

This is true in C just as much as it is in D.

If you want to go at it alone, you have to accept the consequences of your actions.

On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:

> In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test

The docs say it should work:

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

So either the docs are wrong or the implementation is bugged. If there's no issue yet, could you please file one?