- See also PHI1816, which is roughly "all of this" but currently focuses on directory-level coverage aggregation.
See T13105. Previously, files in Diffusion showed a similar coverage column on the right. At time of writing, coverage support hasn't made it to DocumentEngine yet, although I intend to restore it soon.
T11372 / PHI181 want multiple columns of coverage information to support "checked/unchecked" annotations from a static analysis tool. This is conceptually reasonable, although I worry it is so exotic that we'd essentially be building a feature for exactly one install and one narrow use case. Offhand, it's hard to come up with other coverage-like annotations which are interesting and useful. Long ago, T1630 proposed complexity annotations (which might mark particular functions as "red" or "green" or something in between, depending on how complex it is) but I'm not very bought-in to this class of tools being especially useful and there's no current mana behind it. A somewhat-related request in PHI460 discusses an application for recording "ghost stories" about the code -- the mechanism is different, but the goal (warn engineers that they are touching risky code) is similar. I'm better aligned with this as an approach than with automated complexity.
PHI577 reports that this UI previously transposed "Not Executable" and "Not Covered" in tooltips.
These tasks discuss coverage reporting in `arc`:
- {T10331}
- {T8664}
- {T11297}
They are all similar and likely fairly straightforward when `arc unit` gets revamped.
T9524 discusses a potentially substantial improvement to coverage (aggregating it at the directory level in Diffusion).
Currently, coverage is broadly clumsy to interact with. It can be updated in Diffusion with `diffusion.updatecoverage` and in Differential with `harbormaster.sendmessage` but these methods don't interact with one another or share anything.
---
I'm inclined to move gradually toward potentially making coverage modular. Although I don't find the "checked" or "complexity" use cases especially compelling, I don't think they're sufficiently exotic to warrant outright dismissal. Conceptually, support for multiple types of coverage-like information shouldn't be difficult, since a coverage-class is defined by a handful of simple rules (some labels and colors, and some rules for which coverage identifier wins when aggregating coverage). We may never get to a place where we formally support the "checked" or "complexity" cases, but I think modularity has little downside here and may put us in a better place even if we never implement any other types of coverage.