Windows: Single source file with `--single` mentioned twice in compiler command-line (with different slashes)

[kinke]

This has got to be a recent regression, now showing up with the installer smoke tests (the DMD nightlies were broken since March 6th...): https://github.com/dlang/installer/actions/runs/15116939053/job/42490961516?pr=719#step:4:95

$ /d/a/installer/installer/installer/test/release/generated/dmd2/windows/bin/dub.exe run -n --arch=x86_64 --single -v /d/a/installer/installer/installer/test/release/dub_example.d
No valid package found in current working directory: No package file found in D:\a\installer\installer\, expected one of dub.json/dub.sdl/package.json
Generating using build
Configuring dependent dub_example, deps:
    Starting Performing "debug" build using D:\a\installer\installer\installer\test\release\generated\dmd2\windows\bin\dmd.exe for x86_64.
Target 'C:\Users\runneradmin\AppData\Local\dub\cache\dub_example\~master\build\application-debug-105u1Pv9zPRBQp0jEUFdJQ\dub_example.exe' doesn't exist, need rebuild.
    Building dub_example ~master: building configuration [application]
[cwd=D:\a\installer\installer] D:\a\installer\installer\installer\test\release\generated\dmd2\windows\bin\dmd.exe -debug -g -w -version=Have_dub_example installer/test/release/dub_example.d installer\test\release\dub_example.d -m64 -c -ofC:\Users\runneradmin\AppData\Local\dub\cache\dub_example\~master\build\application-debug-105u1Pv9zPRBQp0jEUFdJQ\dub_example.obj -vcolumns
installer\test\release\dub_example.d: Error: module `dub_example` from file installer\test\release\dub_example.d is specified twice on the command line

Note the installer/test/release/dub_example.d installer\test\release\dub_example.d.

[Geod24]

Most likely caused by #2821

[Geod24]

I also don't remember why dub is trying to read the current directory's package recipe. I think there was a rationale for it but it's unintuitive IMO (and might be where the second mention comes from).

[Geod24]

I could reproduce:

mlang_sym@SYMUKLT144 MINGW64 /c/Users
$ /c/Users/mlang_sym/dub/bin/dub run --compiler=dmd -n --arch=x86_64 --single -v /c/Users/mlang_sym/dub/dub_example.d
No valid package found in current working directory: No package file found in C:\Users\, expected one of dub.json/dub.sdl/package.json
Generating using build
Configuring dependent dub_example, deps:
    Starting Performing "debug" build using dmd for x86_64.
Target 'C:\Users\mlang_sym\AppData\Local\dub\cache\dub_example\~master\build\application-debug-D6guM3SFZ-vN_T6W2CflSg\dub_example.exe' doesn't exist, need rebuild.
    Building dub_example ~master: building configuration [application]
[cwd=C:\Users] dmd -debug -g -w -version=Have_dub_example mlang_sym/dub/dub_example.d mlang_sym\dub\dub_example.d -c -ofC:\Users\mlang_sym\AppData\Local\dub\cache\dub_example\~master\build\application-debug-D6guM3SFZ-vN_T6W2CflSg\dub_example.obj -vcolumns
Error: module `test_single` from file mlang_sym\dub\dub_example.d is specified twice on the command line
FAIL C:\Users\mlang_sym\AppData\Local\dub\cache\dub_example\~master\build\application-debug-D6guM3SFZ-vN_T6W2CflSg dub_example executable
Error dmd failed with exit code 1.

However, this requires:

• git bash;
• CWD to not be the directory in which the single file resides;

[kinke]

I guess a workaround would be NOT adding the single file as mainSourceFile too: https://github.com/dlang/dub/blob/879e4186313166f67e69800e1f55166f8df16bd9/source/dub/dub.d#L614-L619

But note that the same string here is used for sourceFiles and mainSourceFile. Edit: I.e., one would expect the duplicates to be filtered out.

[Geod24]

I originally looked at mainSourceFile but I don't think that's the reason. I added a debug logInfo here to print targets and I can see two entries in the sourceFiles:

Configuring dependent dub_example, deps:
             TI: ["dub_example":const(TargetInfo)(const(dub.package_.Package), [const(dub.package_.Package)], "application", const(BuildSettings)(executable, "C:\\Users\\mlang_sym\\dub\\", "dub_example", "", "C:\\Users\\mlang_sym\\dub\\dub_example.d", [], [], [], [], ["C:/Users/mlang_sym/dub/dub_example.d", "C:\\Users\\mlang_sym\\dub\\dub_example.d"], [], [], [], ["Have_dub_example"], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], const(Flags!(BuildRequirement))(const(BitFlags!(BuildRequirement, Flag.no))(0)), const(Flags!(BuildOption))(const(BitFlags!(BuildOption, Flag.no))(65545))), [], [])]

Now going up the stack to see where that comes from. Stack trace:

core.exception.AssertError@source\dub\generators\build.d(78): Assertion failure
----------------
0x00007FF75EAB01AD in d_assert
0x00007FF75E830E21 in dub.generators.build.BuildGenerator.generateTargets at C:\Users\mlang_sym\dub\source\dub\generators\build.d(78)
0x00007FF75E60298A in dub.generators.generator.ProjectGenerator.generate at C:\Users\mlang_sym\dub\source\dub\generators\generator.d(185)
0x00007FF75E840200 in dub.dub.Dub.generateProject at C:\Users\mlang_sym\dub\source\dub\dub.d(796)
0x00007FF75EA33F2E in dub.commandline.GenerateCommand.execute at C:\Users\mlang_sym\dub\source\dub\commandline.d(1510)
0x00007FF75EA343CD in dub.commandline.BuildCommand.execute at C:\Users\mlang_sym\dub\source\dub\commandline.d(1560)
0x00007FF75EA34C95 in dub.commandline.RunCommand.execute at C:\Users\mlang_sym\dub\source\dub\commandline.d(1646)
0x00007FF75E89CAAA in dub.commandline.runDubCommandLine at C:\Users\mlang_sym\dub\source\dub\commandline.d(536)
0x00007FF75EA4526F in app.D main at C:\Users\mlang_sym\dub\source\app.d(39)
0x00007FF75EABDA01 in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll()
0x00007FF75EABD6AB in d_run_main2
0x00007FF75EABD966 in d_wrun_main
0x00007FF75EA47A04 in app.wmain at C:\Program Files\LDC 1.40\import\core\internal\entrypoint.d(32)
0x00007FF75EAD9BE0 in __scrt_common_main_seh at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
0x00007FFE649EE8D7
0x00007FFE6645C5DC in RtlUserThreadStart

[kinke]

FWIW, I expect bash on Windows to automagically replace Cygwin-style paths (/c/Users/mlang_sym/dub/dub_example.d) in the cmdline to c:\Users\mlang_sym\dub\dub_example.d (maybe C drive in uppercase). If dub got a C:/Users/mlang_sym/dub/dub_example.d with fwd slashes, that'd be surprising to me.

[Geod24]

We're not very strict about strings vs paths yet - but the new path module is. There's probably a few things like this through the code: https://github.com/dlang/dub/blob/879e4186313166f67e69800e1f55166f8df16bd9/source/dub/generators/build.d#L261

[Geod24]

Actually it is the mainSourceFile. But I think we should just rely on it and not add it in sourceFiles. Will raise a PR.

[kinke]

Hmm - will that work for the unittests? I've probably never tried it, but I guess dub test --single dir/bla.d might be a thing. Edit: And AFAIK, the mainSourceFile is explicitly excluded from the unittest compile.

[Geod24]

It would lead to a very odd UX since bla.d needs to include a main - if it doesn't it can only be run via dub test but that's not really something we should worry about IMO.

[Geod24]

Edit: I.e., one would expect the duplicates to be filtered out.

There's two issues:

1. We normalize the mainSourceFile before adding it (because it failed another test otherwise);
2. We should be adding NativePath and not string...