UnitTestBot / UnitTestBot/usvm

[TS PBT] Map c8/V8 branch coverage to EtsIR CFG edges

Open
#382 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Kotlin
Stars
33
Forks
27
Avg merge
4d 3h
Merged PRs (30d)
15

Description

Part of #345. Depends on #350. Optional for the property-directed sequential baseline in #354; required before claiming c8/V8 branch-guided search. Selection of a conversion tool should follow the measured cases below, without creating a general converter framework.

Goal

Map branch coverage produced by the pinned c8/V8 backend to TypeScript branch arms and EtsIR CFG edges.

Why

#350 and #381 map backend-neutral binary Istanbul if records to ordered true/false EtsIR successors. The current c8@10.1.3 path uses v8-to-istanbul@9.3.0, which converts every V8 block range into an independent Istanbul-shaped record with type: "branch" and exactly one location/count.

For example, when only the true side of an if/else runs, raw V8 coverage contains a zero-count range for the unexecuted else. When only the false side runs, it contains a zero-count range for the true body. The converted report does not preserve the originating if, the relationship between its arms, or the true/false outcome. It also emits similar records for function and script ranges. Therefore #381 reports these records as UNSUPPORTED instead of guessing CFG edges, while retaining usable statement mappings.

Statement coverage cannot reveal every missed edge. For example, if only the true side of an if without an else runs, every statement may be covered while the false edge remains untested.

Scope

  • Evaluate an AST-aware V8-to-Istanbul converter, including Monocart, before implementing a custom conversion.
  • Preserve enough raw V8 range hierarchy and source-map information to associate coverage with original TypeScript constructs.
  • Produce backend-neutral binary if coverage with explicit true and false arms when the association is exact.
  • Map those arms to ordered EtsIR CFG successors through the mapping layer introduced in #381.
  • Report ambiguous or unsupported cases instead of inferring an edge.
  • Keep successfully mapped statement coverage available when branch reconstruction is not possible.
  • Document which TypeScript branch constructs are supported; do not silently treat switch, conditional expressions, or logical short-circuit ranges as binary if records.

Definition of Done

  • A real c8 run over a TypeScript if/else produces two correctly ordered backend-neutral arms and maps them to the true and false EtsIR successors.
  • Separate true-only, false-only, and mixed executions preserve correct hit counts.
  • Nested conditions, an if without else, source-map remapping, and ambiguous ranges have explicit tests and behavior.
  • Function-level and script-level V8 block ranges are not misclassified as EtsIR conditional edges.
  • Partial failures do not discard exact statement mappings.

Follow-up to #350 and #381.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading #350 and #381, then inspect the mapping layer introduced in #381 and the pinned c8@10.1.3/v8-to-istanbul@9.3.0 path. Evaluate Monocart against the measured cases before choosing an approach. Done means exact if/else arms map to ordered EtsIR successors, while nested, source-mapped, ambiguous, unsupported, and partial-failure cases have explicit tests and preserve statement mappings.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, kotlin, typescript
Domain
compilers, testing-qa, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.