TPF Devel::Cover grant report February 2013

[Paul Johnson]

In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering February 2013.

I have released Devel::Cover 1.00!

So we finally have a stable, functional, well tested release?

Well, no. Or perhaps. Maybe. The reason I have released version 1.00 is
because this is the 100th release of Devel::Cover and I had run out of 0.xy
release numbers.

I had expected to have made some larger interface change before now which
would have justified a major version bump, but that didn't happen. I suppose
that's a good thing. But I do still wonder about changing the interface at
some point - I'm still not really happy with it.

We've had 100 releases in almost 12 years. 21 of those have been within the
last 12 months which has been primarily due to this grant. So thanks to TPF
and everyone who has helped to make this possible.

I wanted to make version 1.00 somewhat special, so I tidied up and documented
(to an extent) the "uncoverable" feature. This is the ability to mark certain
code as uncoverable and have Devel::Cover not flag in as an error when that
code is not exercised. In fact, it will be flagged as an error if it is
exercised.

This is something that people have been asking for for almost as long as
Devel::Cover has existed. The rationale for this feature is similar to that
for TODO tests. If you know that some code cannot be exercised, it is better
to mark it in some formal fashion and stop getting false positive reports
which could mask some real problems. (I've heard that expected failing tests
masking new failures was a problem a fairly high profile project.)

The documentation describes how to use this feature, but there are still a few
edge cases to work on, and the documentation could do with some more detail.

I tested against perl 5.17.8 and there were no problems.

I added all the dual-lifed modules to cpancover as suggested by James E Keenan
in reply to one of my previous reports. The modules were determined with the
following command in the core perl directory:

$ perl -E 'require "Porting/Maintainers.pl"; exists $Maintainers::Modules{$_}{DISTRIBUTION} and say for keys %Maintainers::Modules' | sort

I also increased the cpancover timeout from five minutes to 15 minutes because
some modules have a lot of tests nowadays.

Having PERL5OPT set when running the Devel::Cover tests can cause the tests to
fail. So I have unset PERL5OPT for running the tests to get around that
problem. In fact, it is unset for all Make targets. I'm hoping this isn't
going to cause more problems than it solves. I've heard no screams so far.

I looked into a few old RT tickets. One that took me a little out of my
comfort zone involved $ENV{PWD} on Windows being set within Devel::Cover.
Eventually I narrowed the problem down to:

K:\g\Devel--Cover>perl -v

This is perl 5, version 16, subversion 0 (v5.16.0) built for MSWin32-x64-multi-thread

K:\g\Devel--Cover>set PWD=plpl

K:\g\Devel--Cover>echo %PWD%
plpl

K:\g\Devel--Cover>perl -E "say $ENV{PWD}"
plpl

K:\g\Devel--Cover>perl -MCwd -E "getcwd; say $ENV{PWD}"
K:/g/Devel--Cover

K:\g\Devel--Cover>echo %PWD%
plpl

K:\g\Devel--Cover>

This shows that the problem, if it is a problem, lies within Cwd::getcwd on
Windows. I'd appreciate comments on whether or not this is a bug, but if it
is then it should be filed against the perl core.

Towards the end of the month I started looking into a problem that's needed
some attention for quite a while. The problem that top level statements in
modules (that is statements which are not inside a sub) cannot be covered.

The problem here is not one of collecting the coverage - that is already done.
The problem is that when the programme is ending, and the coverage is being
written to the coverage database, there is no easy way to get at the ops for
which we have collected the coverage in order to be able to correctly report
the coverage. I've not yet solved this, and when I can formulate sensible
questions I'll ask for assistance, unless that process also provides the
answers.

Finally, David Golden politely observed that the coverage reporting for ||=
operators in his Path::Iterator::Rule module was somewhat less than optimal.
So I got hold of the module's source, pared the module down to the minimum
required to reproduce the problem, and fixed it, along with another problem
that showed up too. But some of that work took place in March. The problem
boiled down to C< $x ||= $y > being in void context, but we want to show the
coverage as if were not. In any case, the coverage looks much healthier now:

http://cpancover.com/latest/Path-Iterator-Rule-1.001/blib-lib-Path-Iterator-Rule-pm--condition.html

Closed Github tickets:

45 How to uncoverable the last else in an if-elsif-else?

Merged pull requests:

Closed RT tickets:

#43833 PERL5OPT can make all Devel::Cover tests fail
#48543 Devel::Cover-0.65 persistent test bug + fix
#61775 Clobbering %ENV variable 'PWD' (already fixed?)

You can see the commits at https://github.com/pjcj/Devel--Cover/commits/master

Hours worked:

02.02 6:20
09.02 3:30
11.02 1:45
15:02 4:10
23:02 5:45
28:02 4:50

Total 26:20

Total hours worked on grant: 247:50

[yary]

Thanks for taking the time for tracking down my "bug"-

...$ENV{PWD} on Windows being set within Devel::Cover.
... I'd appreciate comments on whether or not this is a bug, but if it
is then it should be filed against the perl core.

I was the original reporter and I did open a new ticket against path
tools regarding it, after seeing your comments. The module docs for
Cwd state:

If you ask to override your chdir() built-in function,

use Cwd qw(chdir);

then your PWD environment variable will be kept up to date. Note that it
will only be kept up to date if all packages which use chdir import it
from Cwd.

My reading of that is PWD should only be "clobbered" when code uses
Cwd::chdir. Cwd::getcwd is not documented as clobbering PWD. After
posting the ticket, I found that FindBin also clobbers PWD, presumably
also because of its use of Cwd.

One could argue that adding to the docs will fix the issue, but I was
not too pleased to find our code's "password" env var PWD mysteriously
changing.

-y

[Ricardo Signes]

Post by Paul Johnson
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering February 2013.

Great, thanks, +1!

Post by Paul Johnson
Finally, David Golden politely observed that the coverage reporting for ||=
operators in his Path::Iterator::Rule module was somewhat less than optimal.
So I got hold of the module's source, pared the module down to the minimum
required to reproduce the problem, and fixed it, along with another problem
that showed up too.

Especially for that!