On 12/21/2016 11:24 PM, Walter Bright wrote:
> On 12/21/2016 9:43 AM, Johannes Pfau wrote:
>> You need some kind of linker support to do this to provide the
>> start/end symbols.
>
> That's partially correct. I've done this for decades by having the compiler
> itself emit those symbols.
>
> There are other tricks one can do, such as putting the pointers into the
> exception handler tables sections.
>

Or have the compiler call a "registerUnittest()" function with a parameter that's the pointer to the unittest info. Of course, that would require that a registerUnittest function exists somewhere.

On Thursday, 22 December 2016 at 09:10:53 UTC, Walter Bright wrote:
> On 12/21/2016 11:24 PM, Walter Bright wrote:
>> On 12/21/2016 9:43 AM, Johannes Pfau wrote:
>>> You need some kind of linker support to do this to provide the
>>> start/end symbols.
>>
>> That's partially correct. I've done this for decades by having the compiler
>> itself emit those symbols.
>>
>> There are other tricks one can do, such as putting the pointers into the
>> exception handler tables sections.
>>
>
> Or have the compiler call a "registerUnittest()" function with a parameter that's the pointer to the unittest info. Of course, that would require that a registerUnittest function exists somewhere.

I don't know what other people think but the current status of build-in unittests are #1 issue for a quick development. The inability to give test a name (plus selective unittesting) and  continue on failure is puzzling to me.

Cheers,
Piotrek

On 12/22/2016 12:46 PM, Piotrek wrote:
> The inability to give test a name (plus selective unittesting) and
> continue on failure is puzzling to me.

Both of these are affordable with the current language (attributes) with changes to druntime. Who wants to take this? -- Andrei

On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:
> On 12/22/2016 12:46 PM, Piotrek wrote:
>> The inability to give test a name (plus selective unittesting) and
>> continue on failure is puzzling to me.
>
> Both of these are affordable with the current language (attributes) with changes to druntime. Who wants to take this? -- Andrei

I find Atila Neves' unit-threaded useful for running single unittests when using dub, perhaps some inspiration can be found there

https://github.com/atilaneves/unit-threaded

On 2016-12-22 19:19, Andrei Alexandrescu wrote:

> Both of these are affordable with the current language (attributes) with
> changes to druntime. Who wants to take this? -- Andrei

What do you think about this idea [1]?

[1] http://forum.dlang.org/post/npptbk$2mk0$1@digitalmars.com

-- 
/Jacob Carlborg

On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:
> On 12/22/2016 12:46 PM, Piotrek wrote:
>> The inability to give test a name (plus selective unittesting) and
>> continue on failure is puzzling to me.
>
> Both of these are affordable with the current language (attributes) with changes to druntime. Who wants to take this? -- Andrei

I would, but I don't see how this is possible without one of:

1) A standardised build system
2) Changes to the language

Attributes mean static reflection, and that means explicitly (and at compile-time) stating every module being built somewhere. There is no current way to reflect on packages. The only way I know how to do this is to use the build system to autogenerate a D file listing all modules to reflect on, which not coincidentally is how unit-threaded does it, with dub. But it only works if you're using dub and even then fails sometimes if it can't parse `dub describe` properly.

I would've changed druntime 4 years ago if I could, it's the only reason I know of ModuleInfo and what it has to do with unit tests.

Maybe I'm missing something or lacking imagination.

Atila

On Thursday, 22 December 2016 at 17:46:06 UTC, Piotrek wrote:
> On Thursday, 22 December 2016 at 09:10:53 UTC, Walter Bright wrote:
>> On 12/21/2016 11:24 PM, Walter Bright wrote:
>>>[...]
>>
>> Or have the compiler call a "registerUnittest()" function with a parameter that's the pointer to the unittest info. Of course, that would require that a registerUnittest function exists somewhere.
>
> I don't know what other people think but the current status of build-in unittests are #1 issue for a quick development. The inability to give test a name (plus selective unittesting) and  continue on failure is puzzling to me.
>
> Cheers,
> Piotrek

The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries.

Atila

On Thursday, 22 December 2016 at 17:46:06 UTC, Piotrek wrote:
> I don't know what other people think but the current status of build-in unittests are #1 issue for a quick development. The inability to give test a name (plus selective unittesting) and  continue on failure is puzzling to me.



Have you seen my filthy hack for getting individual unittests to continue on failure? http://stackoverflow.com/a/40896271/1457000

It'd be a lot easier though to just actually get the compiler or library to do it. There's so many ways, I personally like the RTInfo for modules approach, it is easy to implement, easy to customize per project, and gives us access to the CT features. But there's others too.

On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
> The worst is how useless plain `assert` is.

I would love it, LOVE it, if assert just printed its info.

Consider the following code:

int a = 0;
int b = 1;

assert(a == b);


Wouldn't it just be glorious if that magically printed:

test.d(4): Assertion failure
    (a == b) is false
    a = 0
    b = 1



I'd also settle for it just showing the left hand and right hand side of the comparison.

assert((0 && 1) == b);
prints: `false == 1 failed`

but it would be REALLY nice if it printed the expression then recursed down and found all the various variable things and printed them too.

assert is built in for a reason, I thought, why then is our built in assert crappier than C's library assert?! Let's make it use the compiler's inside info. Let's make it respond accordingly to its environment (so like assert in contracts may be subtly different than in main bodies or unittests etc)

On Fri, 23 Dec 2016 14:20:44 +0000, Adam D. Ruppe wrote:
> Wouldn't it just be glorious if that magically printed:
> 
> test.d(4): Assertion failure
>      (a == b) is false a = 0 b = 1

I *think* you can do that with an ugly API and string mixins and only needing to parse to the level of parentheses and equality operators.