www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Code coverage in Phobos

reply Seb <seb wilzba.ch> writes:
AFAIK dmd supports the `-cov` flag since quite some time, so I 
would be interested why there's no code coverage bot. There also 
seems to exist at least two external platforms that allow such 
code coverage analyzing [1, 2]. Is this already on your roadmap?

[1] https://github.com/codecov/example-d
[2] https://github.com/ColdenCullen/doveralls/issues/16

Anyways it seems pretty easy to hack something quick&dirty 
together that could be pretty helpful:

```
for f in $(find . -name '*.d' -type f -not -path './c/*'); do 
;fe="${f%.*}"; (cd $(dirname "$f") && rdmd -cov -unittest -main 
"$(basename $f)") && printf "$f " && tail -n1 "$fe".lst | cut -f3 
-d ' ' ; done | sort
```

./algorithm/comparison.d 95%
./algorithm/internal.d no
./algorithm/iteration.d 96%
./algorithm/mutation.d 99%
./algorithm/package.d no
./algorithm/searching.d 97%
./algorithm/setops.d 94%
./algorithm/sorting.d 98%
./array.d 95%
./ascii.d 100%
./base64.d 94%
./bigint.d 97%
./bitmanip.d 96%
./compiler.d no
./complex.d 96%
./concurrencybase.d 100%
./container/array.d 94%
./container/binaryheap.d 59%
./container/dlist.d 92%
./container/package.d 1%
./container/rbtree.d 94%
./container/slist.d 95%
./container/util.d 100%
./conv.d 94%
./cstream.d 92%
./datetime.d 94%
./demangle.d 0%
./digest/crc.d 100%
./digest/digest.d 72%
./digest/hmac.d 100%
./digest/md.d 100%
./digest/ripemd.d 100%
./digest/sha.d 80%
./encoding.d 66%
./exception.d 92%
./experimental/allocator/building_blocks/affix_allocator.d 71%
./experimental/allocator/building_blocks/allocator_list.d 81%
./experimental/allocator/building_blocks/bitmapped_block.d 91%
./experimental/allocator/building_blocks/bucketizer.d 48%
./experimental/allocator/building_blocks/fallback_allocator.d 89%
./experimental/allocator/building_blocks/free_list.d 75%
./experimental/allocator/building_blocks/kernighan_ritchie.d 80%
./experimental/allocator/building_blocks/null_allocator.d 56%
./experimental/allocator/building_blocks/package.d no
./experimental/allocator/building_blocks/quantizer.d 69%
./experimental/allocator/building_blocks/region.d 70%
./experimental/allocator/building_blocks/scoped_allocator.d 78%
./experimental/allocator/building_blocks/segregator.d 50%
./experimental/allocator/building_blocks/stats_collector.d 95%
./experimental/allocator/common.d 88%
./experimental/allocator/gc_allocator.d 92%
./experimental/allocator/mmap_allocator.d 100%
./experimental/allocator/showcase.d 100%
./experimental/allocator/typed.d 54%
./experimental/logger/core.d 99%
./experimental/logger/filelogger.d 91%
./experimental/logger/multilogger.d 100%
./experimental/logger/nulllogger.d 100%
./experimental/logger/package.d no
./experimental/ndslice/internal.d 100%
./experimental/ndslice/iteration.d 100%
./experimental/ndslice/package.d 91%
./experimental/ndslice/selection.d 97%
./experimental/ndslice/slice.d 95%
./file.d 93%
./format.d 92%
./functional.d 88%
./internal/cstring.d 93%
./internal/digest/sha_SSSE3.d 0%
./internal/math/biguintcore.d 58%
./internal/math/biguintnoasm.d 75%
./internal/math/biguintx86.d no
./internal/math/errorfunction.d 92%
./internal/math/gammafunction.d 94%
./internal/processinit.d no
./internal/scopebuffer.d 98%
./internal/test/dummyrange.d 100%
./internal/test/uda.d no
./internal/unicode_comp.d 0%
./internal/unicode_decomp.d 0%
./internal/unicode_grapheme.d no
./internal/unicode_norm.d no
./internal/unicode_tables.d 0%
./internal/windows/advapi32.d no
./json.d 93%
./math.d 92%
./mathspecial.d 47%
./meta.d 97%
./mmfile.d 61%
./net/curl.d 68%
./net/isemail.d 84%
./numeric.d 72%
./outbuffer.d 54%
./parallelism.d 88%
./path.d 97%
./random.d 94%
./range/interfaces.d 78%
./range/package.d 92%
./range/primitives.d 90%
./regex/internal/backtracking.d 0%
./regex/internal/generator.d 56%
./regex/internal/kickstart.d 87%
./regex/internal/parser.d 29%
./regex/internal/tests.d 99%
./regex/internal/thompson.d no
./regex/package.d 90%
./signals.d 92%
./socketstream.d 0%
./stdint.d no
./stdio.d 76%
./stdiobase.d 100%
./stream.d 61%
./string.d 99%
./system.d no
./typecons.d 90%
./typetuple.d 80%
./uni.d 91%
./utf.d 90%
./uuid.d 97%
./variant.d 92%
./windows/charset.d no
./windows/iunknown.d no
./windows/registry.d no
./windows/syserror.d no
./xml.d 64%
./zip.d 90%
./zlib.d 60%
Mar 27 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 01:30:34 UTC, Seb wrote:
 AFAIK dmd supports the `-cov` flag since quite some time, so I 
 would be interested why there's no code coverage bot. There 
 also seems to exist at least two external platforms that allow 
 such code coverage analyzing [1, 2]. Is this already on your 
 roadmap?

 [1] https://github.com/codecov/example-d
 [2] https://github.com/ColdenCullen/doveralls/issues/16

 Anyways it seems pretty easy to hack something quick&dirty 
 together that could be pretty helpful:
Yep. The difficulties are: 1. Getting data off the autotester. Currently it's nearly impossible, as is making any changes to it. https://issues.dlang.org/show_bug.cgi?id=14381 2. Collating data from multiple platforms, as there is a lot of platform-specific code in e.g. std.stdio, std.file, and most of Druntime.
Mar 28 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
wrote:
 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot of 
 platform-specific code in e.g. std.stdio, std.file, and most of 
 Druntime.
3. since the coverage is computed at run-time by the application that runs the tests all the static code (+ CTFE) is considered NOT covered. This gives misleading results. For example std.traits will probably have a bad coverage while actually it's pretty good.
Mar 28 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:
 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:
 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.
3. since the coverage is computed at run-time by the application that runs the tests all the static code (+ CTFE) is considered NOT covered. This gives misleading results. For example std.traits will probably have a bad coverage while actually it's pretty good.
Not really an issue since DMD only counts the code that goes into the binary for coverage. Uncovered lines will have seven zeroes before the |, whereas lines with no compiled code will have nothing.
Mar 28 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 28 March 2016 at 16:44:26 UTC, Vladimir Panteleev 
wrote:
 On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:
 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:
 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.
3. since the coverage is computed at run-time by the application that runs the tests all the static code (+ CTFE) is considered NOT covered. This gives misleading results. For example std.traits will probably have a bad coverage while actually it's pretty good.
Not really an issue since DMD only counts the code that goes into the binary for coverage. Uncovered lines will have seven zeroes before the |, whereas lines with no compiled code will have nothing.
Not true. I wouldn't be able to link an example in Phobos but this is a more general issue with coverage. For example take a file with: template isSomething(T) { bool helper() { return true; // line 5 } enum isSomething = helper; } unittest { bool test; static if (isSomething!bool) {test = true;} assert(test); } and compile with -main -unittest -cov then run. the lst file indicates 00000 for line 5. Actually with `static if()` and helpers functions executed at compile time, 100% coverage is unreachchable. This is more or less the same that happens with if(__ctfe) branches.
Mar 28 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 23:45:10 UTC, Basile B. wrote:
 On Monday, 28 March 2016 at 16:44:26 UTC, Vladimir Panteleev 
 wrote:
 On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:
 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:
 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.
3. since the coverage is computed at run-time by the application that runs the tests all the static code (+ CTFE) is considered NOT covered. This gives misleading results. For example std.traits will probably have a bad coverage while actually it's pretty good.
Not really an issue since DMD only counts the code that goes into the binary for coverage. Uncovered lines will have seven zeroes before the |, whereas lines with no compiled code will have nothing.
Not true. I wouldn't be able to link an example in Phobos but this is a more general issue with coverage. For example take a file with:
Ah, OK. Though, this is something that could be improved in the implementation without changing the language. DMD should not emit code that's not called in the module, and not callable from outside the module due to e.g. being private. Probably would help with template bloat, too. LTO would probably take care of that in theory, I wonder if LDC's or GDC's LTO doesn't have this issue (not that it would help testing Phobos coverage).
Mar 28 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:
 Ah, OK. Though, this is something that could be improved in the implementation
 without changing the language. DMD should not emit code that's not called in
the
 module, and not callable from outside the module due to e.g. being private.
 Probably would help with template bloat, too. LTO would probably take care of
 that in theory, I wonder if LDC's or GDC's LTO doesn't have this issue (not
that
 it would help testing Phobos coverage).
Or one could write unit tests specifically for the helper functions. (I've done that.)
Mar 29 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 29 March 2016 at 09:39:49 UTC, Walter Bright wrote:
 On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:
 Ah, OK. Though, this is something that could be improved in 
 the implementation
 without changing the language. DMD should not emit code that's 
 not called in the
 module, and not callable from outside the module due to e.g. 
 being private.
 Probably would help with template bloat, too. LTO would 
 probably take care of
 that in theory, I wonder if LDC's or GDC's LTO doesn't have 
 this issue (not that
 it would help testing Phobos coverage).
Or one could write unit tests specifically for the helper functions. (I've done that.)
I've also done so in my user lib. Actually I've particpated to this topic because of this: https://issues.dlang.org/show_bug.cgi?id=15590 3 monthes ago I had never used D coverage feature. Initially I thought that the coverage file was generated by static analysis (until someone points me https://dlang.org/phobos/core_runtime.html#.dmd_coverDestPath)... Couldn't the coverage be done at compile time ? (even if I directly see corner cases like functions only called by delegate)
Mar 29 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2016 3:33 AM, Basile B. wrote:
 Couldn't the coverage be done at compile time ?
The implementation for that would be utterly different.
Mar 29 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
wrote:
 On Monday, 28 March 2016 at 01:30:34 UTC, Seb wrote:
 AFAIK dmd supports the `-cov` flag since quite some time, so I 
 would be interested why there's no code coverage bot. There 
 also seems to exist at least two external platforms that allow 
 such code coverage analyzing [1, 2]. Is this already on your 
 roadmap?

 [1] https://github.com/codecov/example-d
 [2] https://github.com/ColdenCullen/doveralls/issues/16

 Anyways it seems pretty easy to hack something quick&dirty 
 together that could be pretty helpful:
Yep. The difficulties are: 1. Getting data off the autotester. Currently it's nearly impossible, as is making any changes to it. https://issues.dlang.org/show_bug.cgi?id=14381 2. Collating data from multiple platforms, as there is a lot of platform-specific code in e.g. std.stdio, std.file, and most of Druntime.
Okay I see that for the long run we need a better way to handle the testing infrastructure :/ Can't we focus for the near future on getting a simple Phobos coverage tester that just compares the coverage of all files changes like your DAutoTest? With this approach we can still prevent regression and show improvements.
Mar 29 2016
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:
 Okay I see that for the long run we need a better way to handle 
 the testing infrastructure :/
Actually the idea of achieving "100% coverage" is that we test every line at least once and don't let this testing by done by users. So to refresh the discussion - there were two general ideas 1) Find "bad", "dangerous" modules, e.g. /xml.d 64% /zlib.d 60% /experimental/allocator/typed.d 54% /experimental/allocator/building_blocks/segregator.d 50% /experimental/allocator/building_blocks/bucketizer.d 48% /encoding.d 66% /container/binaryheap.d 59% /digest/digest.d 72% 2) Increase coverage for generic, platform-independent modules like std.algorithm to 100% I know it's a lot of work, but shouldn't that make our jobs us maintainers easier (=catch the bugs before you have to fix them?). Therefore I am bumping this ;-)
May 24 2016
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote:
 On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:
 Okay I see that for the long run we need a better way to 
 handle the testing infrastructure :/
Actually the idea of achieving "100% coverage" is that we test every line at least once and don't let this testing by done by users. So to refresh the discussion - there were two general ideas 1) Find "bad", "dangerous" modules, e.g. /xml.d 64% /zlib.d 60% /experimental/allocator/typed.d 54% /experimental/allocator/building_blocks/segregator.d 50% /experimental/allocator/building_blocks/bucketizer.d 48% /encoding.d 66% /container/binaryheap.d 59% /digest/digest.d 72% 2) Increase coverage for generic, platform-independent modules like std.algorithm to 100% I know it's a lot of work, but shouldn't that make our jobs us maintainers easier (=catch the bugs before you have to fix them?). Therefore I am bumping this ;-)
Just a quick follow-up on this. I finally managed to work a bit on the export to Codecov.io - it's pretty neat as it will warn reviewers if the coverage decreases due to changes in a PR. Moreover according to Codecov.io, Phobos currently has an overall coverage of 88.15% (the actual coverage is a bit higher, because I had to disable a few tests for Travis and missing, "uncovered" lines are also reported for e.g. deprecated lines). So if someone wants to improve not well-tested modules, at [1] is a list of all modules in Phobos with their coverage. Some highlights include: regex: 51% encoding.d: 62% mathspecial: 57% mmfile: 61% process: 69% socket: 66% zlib: 60% Hopefully in a few days this will be part of Phobos (see [2] for details) and thus automatically updated ;-) [1] https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std [2] https://github.com/dlang/phobos/pull/4587
Jul 09 2016
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 10 July 2016 at 02:38:07 UTC, Seb wrote:
 On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote:
 On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:
 Okay I see that for the long run we need a better way to 
 handle the testing infrastructure :/
Actually the idea of achieving "100% coverage" is that we test every line at least once and don't let this testing by done by users. So to refresh the discussion - there were two general ideas 1) Find "bad", "dangerous" modules, e.g. /xml.d 64% /zlib.d 60% /experimental/allocator/typed.d 54% /experimental/allocator/building_blocks/segregator.d 50% /experimental/allocator/building_blocks/bucketizer.d 48% /encoding.d 66% /container/binaryheap.d 59% /digest/digest.d 72% 2) Increase coverage for generic, platform-independent modules like std.algorithm to 100% I know it's a lot of work, but shouldn't that make our jobs us maintainers easier (=catch the bugs before you have to fix them?). Therefore I am bumping this ;-)
Just a quick follow-up on this. I finally managed to work a bit on the export to Codecov.io - it's pretty neat as it will warn reviewers if the coverage decreases due to changes in a PR. Moreover according to Codecov.io, Phobos currently has an overall coverage of 88.15% (the actual coverage is a bit higher, because I had to disable a few tests for Travis and missing, "uncovered" lines are also reported for e.g. deprecated lines). So if someone wants to improve not well-tested modules, at [1] is a list of all modules in Phobos with their coverage. Some highlights include: regex: 51% encoding.d: 62% mathspecial: 57% mmfile: 61% process: 69% socket: 66% zlib: 60% Hopefully in a few days this will be part of Phobos (see [2] for details) and thus automatically updated ;-) [1] https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std [2] https://github.com/dlang/phobos/pull/4587
Short update - the experiment is now live. Please help to kill the uncovered bits in Phobos :) A short overview of features CodeCov provides: 1) A CodeCov bot will warn the reviewers if (a) the code coverage decreased or (b) there are new, unhit lines added within a PR. 2) For every commit one can browse the current code coverage of all modules https://codecov.io/gh/dlang/phobos/tree/77bee525787a90759211dfeb7103ca608bb44bf0/std 3) They provide a handy dashboard with an overview of historic information https://codecov.io/gh/dlang/phobos (It's a bit empty atm, it might look like this: https://codecov.io/gh/libmir/mir) 4) CodeCov has a bunch of other features, for example browser extensions that integrate the code coverage report directly onto Github diffs: https://github.com/codecov/browser-extension That being said the current approach isn't perfect (see the PR for details), but it's hopefully a start to pay more attention to code coverage ;-)
Jul 28 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 7:16 AM, Seb wrote:
 4) CodeCov has a bunch of other features, for example browser extensions that
 integrate the code coverage report directly onto Github diffs:

 https://github.com/codecov/browser-extension
I installed the browser extension for Chrome, but it says "no coverage" for every Phobos PR I tried it on. Also, the umbrella icon is greyed out. Something's amiss?
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 17:56:49 UTC, Walter Bright wrote:
 On 7/28/2016 7:16 AM, Seb wrote:
 4) CodeCov has a bunch of other features, for example browser 
 extensions that
 integrate the code coverage report directly onto Github diffs:

 https://github.com/codecov/browser-extension
I installed the browser extension for Chrome, but it says "no coverage" for every Phobos PR I tried it on. Also, the umbrella icon is greyed out. Something's amiss?
Hmm I guess we bumped into this issue: https://github.com/codecov/browser-extension/issues/22 - last time their support team was pretty fast, so I hope we can resolve this issue soon :) Do you see the Code coverage overlay for this diff? https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540 and on this file? https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d Older PRs don't show a coverage report, because the report needs to be uploaded & they don't have this in their `.travis.yml` yet. However rebasing should fix this.
Jul 28 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 11:51 AM, Seb wrote:
 Do you see the Code coverage overlay for this diff?

 https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540
Yes. Took me a moment to realize the green box meant covered.
 and on this file?

 https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d
Yes.
 Older PRs don't show a coverage report, because the report needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However rebasing should fix
 this.
Thanks! Looks like I'll rebase all of my PRs and we'll see how it works!
Jul 28 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 11:51 AM, Seb wrote:
 Older PRs don't show a coverage report, because the report needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However rebasing should fix
 this.
I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No coverage]
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 20:30:50 UTC, Walter Bright wrote:
 On 7/28/2016 11:51 AM, Seb wrote:
 Older PRs don't show a coverage report, because the report 
 needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However 
 rebasing should fix
 this.
I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No coverage]
... but it shows that those three lines are never hit ;-) As far as I understood [1] the problem is that the CodeCov browser extension has troubles handling merge commits. I will ping you once they resolved the issue and the PR view is working. For now you can click on "Last update 6db08d3...bb94012" to see the diff with overlayed code coverage. [1] https://github.com/codecov/browser-extension/issues/22
Jul 28 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 1:46 PM, Seb wrote:
 For now you can click on "Last update 6db08d3...bb94012" to see the diff with
 overlayed code coverage.
I don't see where that link is.
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 23:11:04 UTC, Walter Bright wrote:
 On 7/28/2016 1:46 PM, Seb wrote:
 For now you can click on "Last update 6db08d3...bb94012" to 
 see the diff with
 overlayed code coverage.
I don't see where that link is.
Sorry about being so vague. e.g. on this PR (https://github.com/dlang/phobos/pull/4657), there is the following message. The link "Last update" is on the last line. Current coverage is 88.68% (diff: 87.09%) Merging #4655 into master will increase coverage by <.01% master #4655 diff ========================================== Files 121 121 Lines 73827 73849 +22 Methods 0 0 Messages 0 0 Branches 0 0 ========================================== + Hits 65471 65492 +21 - Misses 8356 8357 +1 Partials 0 0 Powered by Codecov. Last update 6db08d3...2002c65 <-- CLICK HERE
Jul 28 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 4:39 PM, Seb wrote:
 e.g. on this PR (https://github.com/dlang/phobos/pull/4657), there is the
 following message. The link "Last update" is on the last line.
Ok, I see it now. Thanks!
Jul 28 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 20:46:13 UTC, Seb wrote:
 On Thursday, 28 July 2016 at 20:30:50 UTC, Walter Bright wrote:
 On 7/28/2016 11:51 AM, Seb wrote:
 Older PRs don't show a coverage report, because the report 
 needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However 
 rebasing should fix
 this.
I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No coverage]
... but it shows that those three lines are never hit ;-) As far as I understood [1] the problem is that the CodeCov browser extension has troubles handling merge commits. I will ping you once they resolved the issue and the PR view is working. For now you can click on "Last update 6db08d3...bb94012" to see the diff with overlayed code coverage. [1] https://github.com/codecov/browser-extension/issues/22
The CodeCov support team is really nice & fast. They found the issue [1] and deployed it today. So the Code coverage browser extension is working for all PRs built on Travis starting from today, e.g. [2] :) [1] https://github.com/codecov/support/issues/263 [2] https://github.com/dlang/phobos/pull/4693/files
Jul 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 12:05 PM, Seb wrote:
 The CodeCov support team is really nice & fast. They found the issue [1] and
 deployed it today. So the Code coverage browser extension is working for all
PRs
 built on Travis starting from today, e.g. [2] :)

 [1] https://github.com/codecov/support/issues/263
 [2] https://github.com/dlang/phobos/pull/4693/files
[2] says [No coverage] and clicking on it says "Coverage not found" :-(
Jul 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 30 July 2016 at 22:35:45 UTC, Walter Bright wrote:
 On 7/30/2016 12:05 PM, Seb wrote:
 The CodeCov support team is really nice & fast. They found the 
 issue [1] and
 deployed it today. So the Code coverage browser extension is 
 working for all PRs
 built on Travis starting from today, e.g. [2] :)

 [1] https://github.com/codecov/support/issues/263
 [2] https://github.com/dlang/phobos/pull/4693/files
[2] says [No coverage] and clicking on it says "Coverage not found" :-(
You got bad luck, 9il added a commit (so the last commit changed) & the build is currently running and thus "No coverage" is reported. You might try another PR like: https://github.com/dlang/phobos/pull/4647/files
Jul 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 3:40 PM, Seb wrote:
 You might try another PR like:

 https://github.com/dlang/phobos/pull/4647/files
Much better. Thanks!
Jul 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 3:40 PM, Seb wrote:
 [...]
Ok, it's time to get this rolling for Druntime, too!
Jul 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 30 July 2016 at 23:50:08 UTC, Walter Bright wrote:
 On 7/30/2016 3:40 PM, Seb wrote:
 [...]
Ok, it's time to get this rolling for Druntime, too!
https://github.com/dlang/druntime/pull/1620 ;-)
Jul 30 2016
parent Seb <seb wilzba.ch> writes:
On Sunday, 31 July 2016 at 02:08:23 UTC, Seb wrote:
 On Saturday, 30 July 2016 at 23:50:08 UTC, Walter Bright wrote:
 On 7/30/2016 3:40 PM, Seb wrote:
 [...]
Ok, it's time to get this rolling for Druntime, too!
https://github.com/dlang/druntime/pull/1620 ;-)
It turns out it's not that difficult to get it working for DMD, too! :) https://github.com/dlang/dmd/pull/5990
Jul 30 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 7:16 AM, Seb wrote:
 Short update - the experiment is now live. Please help to kill the uncovered
 bits in Phobos :)
Thank you very much for doing this! Raising the visibility of code coverage will push towards much better unittesting of Phobos.
Jul 28 2016