would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
eg use case:

# compile with unittests just for package foo (excluding subpackage foo.bar) dmd -unittest=foo -unittest=-foo.bar -i main.d

On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wrote:
> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?

so when this came up on irc earlier (was that you?) this was the first thought that came to my mind. I'd support it, tho I'm no decision maker.

I originally proposed it here: https://forum.dlang.org/post/mailman.3166.1517969180.9493.digitalmars-d@puremagic.com but it was buried under another thread

On Wed, Mar 14, 2018 at 3:04 PM, Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wrote:
>>
>> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
>
>
> so when this came up on irc earlier (was that you?) this was the first thought that came to my mind. I'd support it, tho I'm no decision maker.

On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wrote:
> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
> wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
> eg use case:
>
> # compile with unittests just for package foo (excluding subpackage foo.bar) dmd -unittest=foo -unittest=-foo.bar -i main.d

I'm in favor. If you decide to create a PR, all the match logic is in mars.d at the end of the file. Might want to move it to another module.

On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wrote:
> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
> wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
> eg use case:
>
> # compile with unittests just for package foo (excluding subpackage foo.bar) dmd -unittest=foo -unittest=-foo.bar -i main.d

Hmm how would this solve the StdUnittest use case? I.e. that templated phobos unittests and private unittest symbols are compiled into the users unittests?

See also:

https://github.com/dlang/phobos/pull/6202
https://github.com/dlang/phobos/pull/6159

On Thursday, 15 March 2018 at 05:22:45 UTC, Seb wrote:

> Hmm how would this solve the StdUnittest use case? I.e. that templated phobos unittests and private unittest symbols are compiled into the users unittests?
>
> See also:
>
> https://github.com/dlang/phobos/pull/6202
> https://github.com/dlang/phobos/pull/6159

I would hope this would be solvable without the having the user do something, like `-unittest=<pattern>`.

--
/Jacob Carlborg

On Thu, Mar 15, 2018 at 12:14:12PM +0000, Jacob Carlborg via Digitalmars-d wrote:
> On Thursday, 15 March 2018 at 05:22:45 UTC, Seb wrote:
> 
> > Hmm how would this solve the StdUnittest use case? I.e. that templated phobos unittests and private unittest symbols are compiled into the users unittests?
> > 
> > See also:
> > 
> > https://github.com/dlang/phobos/pull/6202 https://github.com/dlang/phobos/pull/6159
> 
> I would hope this would be solvable without the having the user do something, like `-unittest=<pattern>`.
[...]

Even that would be preferable to the current situation.


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson

On Thursday, March 15, 2018 07:17:47 H. S. Teoh via Digitalmars-d wrote:
> On Thu, Mar 15, 2018 at 12:14:12PM +0000, Jacob Carlborg via Digitalmars-d
wrote:
> > On Thursday, 15 March 2018 at 05:22:45 UTC, Seb wrote:
> > > Hmm how would this solve the StdUnittest use case? I.e. that templated phobos unittests and private unittest symbols are compiled into the users unittests?
> > >
> > > See also:
> > >
> > > https://github.com/dlang/phobos/pull/6202 https://github.com/dlang/phobos/pull/6159
> >
> > I would hope this would be solvable without the having the user do something, like `-unittest=<pattern>`.
>
> [...]
>
> Even that would be preferable to the current situation.

Being able to run easily run the unit tests for a specific module without much effort would be nice, but as far as the overall unittest problem goes, it doesn't really fix it, just work around it.

And if all we're looking for is a workaround, we can always use a project-specific version identifier and version off the unit test code - and that works right now without any compiler changes. It gives full control of the situation and gives essentially what we really want in terms of the resulting binary. It also ensures that projects importing you're library don't end up with your unit test code in their project no matter how they compile theirs (short of figuring out your project-specific version identifier and explicitly compiling with it for some, weird reason anyway). It's just a really sucky thing to have to do. I was forced to do it with dxml though due to a weird linker error that projects importing dxml got when building their unit tests.

What we really want is essentially what such a project-specific version identifier does but without having to use a project-specific identfier.

- Jonathan M Davis

On Thursday, 15 March 2018 at 12:14:12 UTC, Jacob Carlborg wrote:
> On Thursday, 15 March 2018 at 05:22:45 UTC, Seb wrote:
>
>> Hmm how would this solve the StdUnittest use case? I.e. that templated phobos unittests and private unittest symbols are compiled into the users unittests?
>>
>> See also:
>>
>> https://github.com/dlang/phobos/pull/6202
>> https://github.com/dlang/phobos/pull/6159
>
> I would hope this would be solvable without the having the user do something, like `-unittest=<pattern>`.
>
> --
> /Jacob Carlborg

... exactly my point, but I think I misunderstood the goal of -unittest=<pattern>. It's solely about being able to filter selectively for which unittests to run, which is a noble goal itself.

A bit of background regarding StdUnittest
-----------------------------------------

To explain the need for StdUnittest to people who haven't been following up on the discussion have a look at https://github.com/dlang/phobos/pull/5927 which introduced StdUnittest initially.

There are a few examples in this PR:

1) short-path version(unittest) in a symbol was done in production code too (see https://github.com/dlang/phobos/pull/5932)

2) The unittest in templated aggregates are compiled and executed whenever the users uses the templates (see also: https://wiki.dlang.org/DIP82)

3) version(unitest) symbols which are added for unittest are still visible and compiled into user code. Of course this should be fixed with `private`, but even then the compiler still looks at the symbol, which it wouldn't do with StdUnittest (see Vladimir's comment about import time https://github.com/dlang/phobos/pull/6159#issuecomment-365290004)

Now StdUnitest was reverted because -deps compiles ALL code and thus lead to breakage in downstream packages, see https://github.com/dlang/phobos/pull/6159 for the discussion

On 3/14/18 5:22 PM, Timothee Cour wrote:
> would a PR for `dmd -unittest=<pattern> (same syntax as -i)` be welcome?
> wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
> eg use case:
> 
> # compile with unittests just for package foo (excluding subpackage foo.bar)
> dmd -unittest=foo -unittest=-foo.bar -i main.d
> 

Note, we can do a lot with just runtime options as well. The code to run all the unit tests could easily be changed to deal with such patterns. But this only affects unit test functions inside those modules, it doesn't affect unit tests inside template types (or version(unittest) statements).

We really should have a way to control both static unittest compilation on a modular level, and also which modules' unit tests are run at runtime.

For example, you may actually wish to enable version(unittest) for module foo, so you can test using a template inside foo with a type from bar, but you may only then want to run bar's unittest functions (where the template is actually instantiated and the unittest would be run).

-Steve