Re: [Caml-list] [ANN] Bisect_ppx 1.0.0 – Modernized code coverage for OCaml

[Anton Bachin <antonbachin@yahoo.com>]

Hi David,

Thanks for your comments.

> * l. 107, 'let try_finally x f h =' is not green. The function seems to be called as l. 108 is green. (Same remark for all defined functions)
>   https://rleonid.github.io/bisect_ppx/coverage/file0004.html#L107

This is an oversight on our part. We mark expressions in module-level
let-bindings, and not the let-bindings themselves. The idea is that the
expression is reached if and only if the let-binding is reached. That is
why you see the mark on the next line. However, in case the let binding
has parameters, our marking is wrong. Right now we handle

  let x = (* mark *) 1

correctly and

  let f x = (* mark *) 1

incorrectly, because that desugars to

  let f = (* no mark! *) fun x -> (* mark *) 1

The actual problem is very likely marks occupying the same location. In any
case, I’ve opened an issue for dealing with this:

https://github.com/rleonid/bisect_ppx/issues/81

> * l. 110, 'f x' is not green? 'f' seems to be called if the previous "try" is green.
>   https://rleonid.github.io/bisect_ppx/coverage/file0004.html#L110

The “f x” in try is evaluated if and only if the whole try-expression is
evaluated – unless, perhaps, the *implementation* of exception handling can
cause a memory or stack overflow exception to occur between these two points –
can someone knowledgeable comment? However, assuming my previous statement is
correct, it’s not necessary to have a mark in both places. We chose to put the
mark on “try” because it is technically very slightly easier to do so. However,
we could be convinced to move it to the expression instead.

> * l. 139, '^ ".cmp"' is not green? Once again, this expression seems to executed by your tests.
>   https://rleonid.github.io/bisect_ppx/coverage/file0004.html#L139

Thanks. We are now looking into putting marks on function arguments. It will
require some investigation to do correctly and legibly for all cases (e.g. infix
operators). Not sure why this wasn’t done in original Bisect. If we find a good
reason for *not* doing it, we will document it.

https://github.com/rleonid/bisect_ppx/issues/82

> * l. 168 and l. 169, 'else' is never coloured? For me, it should be green l. 168 and red l. 170.
>   https://rleonid.github.io/bisect_ppx/coverage/file0004.html#L168

To the best of my knowledge, we can’t get the location of the else keyword in an
if-then-else in PPX. That’s why we mark at the start of the subexpressions.

> Overall, I would expect all code lines to be either green, red or yellow, not without colour (except for comments and type and exception definitions).

Bisect_ppx colors expressions and not lines – the line colors just indicate
whether there is a colored expression on each line. So, yes, while many lines in
expressions should be colored, some won’t be – for example, from above, lines
containing only delimiters such as “then”, “else”, and “end”.


We are looking to extend coverage analysis as much as reasonably possible, so
thanks again, and do let us know if you find any other gaps :)


Regards,
Anton