Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Devel-Cover CPAN distribution.

Report information
The Basics
Id: 63090
Status: resolved
Priority: 0/
Queue: Devel-Cover

People
Owner: Nobody in particular
Requestors: MITHALDU [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 0.73
  • 0.87
  • 0.93
Fixed in: (no value)



Subject: conditionals where one element is data from a Moose attrib are not evaluated
I have a small script, which seems to demonstrate a bug in Devel::Cover: https://gist.github.com/703513 What happens is that the code runs through and the || condition is properly evaluated and both paths exercised as demonstrated by the output. However the condition evaluation of Devel::Cover claims the || was neither true nor false at any point. This seems to be caused by "meep" being a moose attribute sub AND the attempt to use data from the hash it returns. The || is evaluated properly if the "->{marp}" part is left off, or when meep is replaced with a fully declared sub-routine.
Forgot to note this: As far as i can tell this is independent of perl version or platform. I asked around on IRC and it was reproduced across multiple perl versions and platforms, from windows, to linux, to solaris.
Thanks very much for this report. It is fixed by 4283f27 and your test case has been added as a test.
I just got some coverage on code and it seems this is not yet fixed for me. You can see output on the example script i gave you in this gist: https://gist.github.com/703513#file_output+with+dc+0.87
And a test output from Tux demonstrating that this behavior is consistent across OSes and perl versions: http://pasta.test-smoke.org/264
Turns out that this behavior is ok, since the fix wasn't actually released yet. However a very similar issue has been found in Moo: https://github.com/pjcj/Devel--Cover/pull/20/files
To ping this, the pull request still demonstrates the issue tersely and the issue still exists.
Thanks for the updated report. This has been fixed by eedecbd which will be in the next release. Thanks again,