On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
> Glad to announce D 2.078.0.
>
> This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks.
>
> Thanks to everyone involved in this 👏 https://dlang.org/contributors.html.
>
> http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html
>
> - -Martin

What is the purpose of the coverage option "srcpath"?

In my scenario I have a folder "dependencies" and a folder "source". I want to generate
code coverage only for the files in folder "source".

dmd -unittest -cov source/app.d dependencies/dep.d
app.exe --DRT-covopt="srcpath:./source dstpath:./cov"

By specifying "srcpath" there are 2 empty files created in folder cov:
source-app.lst
dependencies-dep.lst

I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source...

Kind regards
André

DMD64 2.078.0 on Linux and macOS is taking wildly longer to build and run unittests for mir-algorithm. The extra time appears to be related to release mode optimizations.

Build logs:
https://travis-ci.org/libmir/mir-algorithm/builds/324052159

DMD 2.077.1 for linux32: 3 min 20 sec
DMD 2.077.1 for linux64: 3 min 16 sec
DMD 2.077.1 for mac64: 5 min 4 sec

DMD 2.078.0-rc.1 for linux32: 13 min 30 sec
DMD 2.078.0-rc.1 for linux64: 9 min 39 sec
DMD 2.078.0-rc.1 for mac64: 10 min 56 sec, then the job was aborted

The above tests all include a non-release build and a release build. On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck".

I don't see any new compiler optimizations in the changelog. Any idea of what could be causing this?

On Wednesday, 10 January 2018 at 21:32:55 UTC, Nathan S. wrote:
> On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck".

When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining.

On Wednesday, 10 January 2018 at 21:42:38 UTC, Nathan S. wrote:
> When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining.

filed so we don't forget: https://issues.dlang.org/show_bug.cgi?id=18221

On Wednesday, 10 January 2018 at 05:35:05 UTC, Andre Pany wrote:
> On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
>> Glad to announce D 2.078.0.
>>
>> This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks.
>>
>> Thanks to everyone involved in this 👏 https://dlang.org/contributors.html.
>>
>> http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html
>>
>> - -Martin
>
> What is the purpose of the coverage option "srcpath"?
>
> In my scenario I have a folder "dependencies" and a folder "source". I want to generate
> code coverage only for the files in folder "source".
>
> dmd -unittest -cov source/app.d dependencies/dep.d
> app.exe --DRT-covopt="srcpath:./source dstpath:./cov"
>
> By specifying "srcpath" there are 2 empty files created in folder cov:
> source-app.lst
> dependencies-dep.lst
>
> I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source...

From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code.

* https://dlang.org/code_coverage.html#switchsrcpath
* https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84
* https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211

BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :).

On Friday, 12 January 2018 at 10:13:13 UTC, Leandro Lucarella wrote:
>
> From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code.
>
> * https://dlang.org/code_coverage.html#switchsrcpath
> * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84
> * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211
>
> BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :).

Thanks for the clarification.

Kind regards
André

On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
>
> Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough
>
> [Environment64]
> LIB=%@P%\..\lib64
> DFLAGS=%DFLAGS% -L/OPT:NOICF
>
> When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017.

Any chance to get the corresponding PR with 2.078.1 point release?
I also tried it with the Build Tools for Visual Studio 2017 and it neither works.

I think the link path could be easily retrieved.
You could check whether the first element of %PATH% contains a file link.exe
and use this one if the file path also starts with %VCINSTALLDIR%.

Example:
Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;...

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\

Kind regards
André

On 12.01.2018 12:42, Andre Pany wrote:
> On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
>>
>> Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough
>>
>> [Environment64]
>> LIB=%@P%\..\lib64
>> DFLAGS=%DFLAGS% -L/OPT:NOICF
>>
>> When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017.
> 
> Any chance to get the corresponding PR with 2.078.1 point release?
> I also tried it with the Build Tools for Visual Studio 2017 and it neither works.
> 
> I think the link path could be easily retrieved.
> You could check whether the first element of %PATH% contains a file link.exe
> and use this one if the file path also starts with %VCINSTALLDIR%.
> 
> Example:
> Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;...
> 
> VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\
> 
> Kind regards
> André
> 

IMO removing the detected entries from sc.ini should be good enough: https://github.com/dlang/dmd/pull/7686. The linker path is built from the other VC variables. I've based it on stable in the hope it will make it into 2.078.1.

The more involved changes I mentioned are https://github.com/dlang/installer/pull/281 and https://github.com/dlang/dmd/pull/7500.

On Friday, 12 January 2018 at 18:25:37 UTC, Rainer Schuetze wrote:
>
> IMO removing the detected entries from sc.ini should be good enough: https://github.com/dlang/dmd/pull/7686. The linker path is built from the other VC variables. I've based it on stable in the hope it will make it into 2.078.1.
>
> The more involved changes I mentioned are https://github.com/dlang/installer/pull/281 and https://github.com/dlang/dmd/pull/7500.

Thanks for your great work!

Kind regards
Andre