• Chris Katko (101/101) Dec 11 2021 Running 64-bit Linux
• russhy (4/4) Dec 12 2021 You are running the beta version of the compiler, and an older
• Andre Pany (11/16) Dec 13 2021 I really recommend always using dub configurations, especially
• Andre Pany (5/22) Dec 16 2021 Sample can be found here:
• Steven Schveighoffer (9/39) Dec 13 2021 `dub test` adds its own main file, and removes yours. So essentially,

Chris Katko <ckatko gmail.com> writes:

Running 64-bit Linux
```
dmd --version
DMD64 D Compiler v2.098.0-beta.2

dub --version
DUB version 1.27.0-beta.2, built on Sep  7 2021
```

the following code 'compiles' in one project.

```d
unittest
{
gasdindgaslkdgansklnasgdlknaglkgansklsdg;
}

void main(){} // compiles, links, and 'runs unit tests'
```

dub
[shows compiling, linking, then runs]

dub test

```
Running dfile-test-library
All unit tests have been run successfully.
```

Which made no sense whatsoever until I placed it into a second, 
different DUB project and catches it immediately using the same 
commands and test.

In a separate dub project I get the error message:

```
widescreen ~main: building configuration "application"...
source/app.d(4,1): Error: undefined identifier 
`gasdindgaslkdgansklnasgdlknaglkgansklsdg`
/usr/bin/dmd failed with exit code 1.
```


I'm not doing anything special with DUB and made both projects 
within a couple weeks of each other. I tried dub clean, dub, dub 
test. Still broken.



dub.json for broken project
```json
{
	"authors": [
		"chris"
	],
	"copyright": "Copyright © 2021, chris",
	"dependencies": {
		"crypto": "~>0.2.16"
	},
	"description": "A minimal D application.",
	"license": "proprietary",
	"name": "dfile"
}
```

dub.json for working project
```json
{
	"authors": [
		"chris"
	],
	"copyright": "Copyright © 2021, chris",
	"description": "A minimal D application.",
	"license": "proprietary",
	"name": "widescreen"
}
```

dub.json.selections (for broken project only)
```json
{
	"fileVersion": 1,
	"versions": {
		"crypto": "0.2.16",
		"intel-intrinsics": "1.6.1"
	}
}
```

Other than unit testing being broken, everything seems to work 
fine. I even deleted 99.9% of my code and left only the bad 
unittest code and a main, and it still compiles.


Could it be a bug where the previous unit test (at some point) 
was valid, and it's caching and still running that one? I have a 
/.dub/code/ d file I found:

```d
module dub_test_root;
import std.typetuple;
static import notes;
alias allModules = TypeTuple!(notes);

						import std.stdio;
						import core.runtime;

						void main() { writeln("All unit tests have been run 
successfully."); }
						shared static this() {
							version (Have_tested) {
								import tested;
								import core.runtime;
								import std.exception;
								Runtime.moduleUnitTester = () => true;
								enforce(runUnitTests!allModules(new 
ConsoleTestResultWriter), "Unit tests failed.");
							}
						}
```

Which doesn't appear in the "correct, not compiling" project 
directory which appears just empty. Possibly because it never 
successfully compiled a unit test suite.

russhy <russhy_s gmail.com> writes:

You are running the beta version of the compiler, and an older 
version of LDC2

I'd first try to update them to make sure you aren't missing any 
bug fixes

Andre Pany <andre s-e-a-p.de> writes:

On Sunday, 12 December 2021 at 05:54:44 UTC, Chris Katko wrote:
 Running 64-bit Linux
 ```
 dmd --version
 DMD64 D Compiler v2.098.0-beta.2

 [...]

I really recommend always using dub configurations, especially 
when you want to use unit tests.

The name of the first configuration doesn't matter. It is used by 
default for commands dub, dub build...
The second configuration you name "unittest". This configuration 
is automatically used by command dub test.

In configuration "unittest" you additionally specify 
"mainSourceFile".

Kind regards
Andre

Andre Pany <andre s-e-a-p.de> writes:

On Monday, 13 December 2021 at 18:24:07 UTC, Andre Pany wrote:
 On Sunday, 12 December 2021 at 05:54:44 UTC, Chris Katko wrote:
 Running 64-bit Linux
 ```
 dmd --version
 DMD64 D Compiler v2.098.0-beta.2

 [...]

 I really recommend always using dub configurations, especially 
 when you want to use unit tests.

 The name of the first configuration doesn't matter. It is used 
 by default for commands dub, dub build...
 The second configuration you name "unittest". This 
 configuration is automatically used by command dub test.

 In configuration "unittest" you additionally specify 
 "mainSourceFile".

 Kind regards
 Andre

Sample can be found here:
https://andre2007.github.io/d-tips/dub/application_template/

Kind regards
André

Steven Schveighoffer <schveiguy gmail.com> writes:

On 12/12/21 12:54 AM, Chris Katko wrote:
 Running 64-bit Linux
 ```
 dmd --version
 DMD64 D Compiler v2.098.0-beta.2
 
 dub --version
 DUB version 1.27.0-beta.2, built on Sep  7 2021
 ```
 
 the following code 'compiles' in one project.
 
 ```d
 unittest
 {
 gasdindgaslkdgansklnasgdlknaglkgansklsdg;
 }
 
 void main(){} // compiles, links, and 'runs unit tests'
 ```
 
 dub
 [shows compiling, linking, then runs]
 
 dub test
 
 ```
 Running dfile-test-library
 All unit tests have been run successfully.
 ```
 

`dub test` adds its own main file, and removes yours. So essentially, 
it's not building your app.d file at all.

`dub test` is a utility used to test libraries, which typically do not 
have a main function. It's definitely suspect for dub to do this, and 
it's based on historical baggage.

To test an application with dub, use `dub -b unittest`, which builds the 
application the same as always, just with the `-unittest` switch.

-Steve