On Fri, Sep 03, 2021 at 01:12:13AM +0000, deadalnix via Digitalmars-d wrote:
> On Friday, 3 September 2021 at 00:09:37 UTC, H. S. Teoh wrote:
> > Would this satisfy everybody?
> > 
> 
> 1/ make module the default. This is really the sensible behavior. Changing imports really change the list of test that are run, especially not recursively.

Making module the default would break existing usage. But whatever, the important thing is to implement -unittest=xxx first, then changing the default is a 1-line change later.


> 2/ the `-main` problem remains.

Even though it's kinda related, -main is really an orthogonal issue. I've also run into the problem myself where -main is needed when your modules don't contain main() but must be suppressed or worked around when it does declare main().  This should be fixed so that -main *optionally* inserts an empty main(), e.g., as a weak symbol, or whatever, so that the existence of a real main() doesn't cause a linker error.


> 3/ it still isn't possible to run the unit tests of several modules in one go by passing a list of modules to the compiler (in the same way you can compile several modules in one go and generate an object file for all of them at once).

Of course you can.  Under my proposal:

	dmd -unittest=module -i -run mod1.d mod2.d mod3.d main.d


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On Friday, 3 September 2021 at 03:06:27 UTC, H. S. Teoh wrote:
>> 2/ the `-main` problem remains.
>
> Even though it's kinda related, -main is really an orthogonal issue. I've also run into the problem myself where -main is needed when your modules don't contain main() but must be suppressed or worked around when it does declare main().  This should be fixed so that -main *optionally* inserts an empty main(), e.g., as a weak symbol, or whatever, so that the existence of a real main() doesn't cause a linker error.
>
>

Well, yes and no. It can be solved in an orthogonal fashion, but this really is the same problem: the flag you can pass to the compiler are doing nonsensical stuff and are not amendable to common use cases.

>> 3/ it still isn't possible to run the unit tests of several modules in one go by passing a list of modules to the compiler (in the same way you can compile several modules in one go and generate an object file for all of them at once).
>
> Of course you can.  Under my proposal:
>
> 	dmd -unittest=module -i -run mod1.d mod2.d mod3.d main.d
>

No, this will run the code in mod1.d , passing ["mod2.d" "mod3.d" "main.d"] as command line arguments.

On Fri, Sep 03, 2021 at 08:39:35AM +0000, deadalnix via Digitalmars-d wrote: [...]
> > > 3/ it still isn't possible to run the unit tests of several modules in one go by passing a list of modules to the compiler (in the same way you can compile several modules in one go and generate an object file for all of them at once).
> > 
> > Of course you can.  Under my proposal:
> > 
> > 	dmd -unittest=module -i -run mod1.d mod2.d mod3.d main.d
> > 
> 
> No, this will run the code in mod1.d , passing ["mod2.d" "mod3.d" "main.d"] as command line arguments.

Oh right, this is the other bogonity of -run: it expects the following argument to be the module that gets run.  I really don't understand the logic of this: surely the compiler ought to be able to know which module main() is declared in, so why does it need the user to select one specific module to be run?  This should be automated within the compiler itself.


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.

On Sun, Sep 05, 2021 at 03:52:51PM +0000, jfondren via Digitalmars-d wrote:
> On Sunday, 5 September 2021 at 15:04:58 UTC, H. S. Teoh wrote:
> > On Fri, Sep 03, 2021 at 08:39:35AM +0000, deadalnix via Digitalmars-d wrote: [...]
> > > > > 	dmd -unittest=module -i -run mod1.d mod2.d mod3.d main.d
> > > >
> > > 
> > > No, this will run the code in mod1.d , passing ["mod2.d" "mod3.d" "main.d"] as command line arguments.
> > 
> > I really don't understand the logic of this: surely the compiler ought to be able to know which module main() is declared in, so why does it need the user to select one specific module to be run?
> 
> ```
> $ grep -H . mod?.d
> mod1.d:void main(string[] args) {
> mod1.d:    import std.stdio : writeln;
> mod1.d:    writeln(args[1 .. $]);
> mod1.d:}
> $ dmd -run mod1.d mod2.d mod3.d
> ["mod2.d", "mod3.d"]
> ```
> 
> mod1.d is a program that prints its args that I'd like to run with some arguments. mod2.d and mod3.d are not modules that even exist; I just want them printed out like that. Distinguishing between dmd and program arguments isn't a matter of compiler smarts.

This is seriously a wrong conflation of the program arguments with a program module.  If the whole point is to support specifying the command-line to the program, then the argument list should appear immediately after -run; the first argument after -run should not be conflated with argv[0]. (For example, what if I'm writing an analogue of busybox, and need to specify a different argv[0] from the name of the executable?)

The current behaviour is counterintuitive, doesn't cover all use cases, and has inconsistencies that lead to confusion.  It's poor design.


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom

On Sunday, 5 September 2021 at 16:12:26 UTC, H. S. Teoh wrote:
> The current behaviour is counterintuitive, doesn't cover all use cases, and has inconsistencies that lead to confusion.  It's poor design.
>

I'm glad that, one by one, people are waking up to this fact. It took 80+ messages, but we're getting there.

This is especially bonkers in the unittest case, because we are not even planning to run main.