UnitTestBot / UnitTestBot/usvm

[TS PBT] Project property domains and preconditions into USVM

Open
#351 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 and the shared-contract gate #384.

Goal

Construct symbolic inputs and precondition constraints from the existing Kotlin property domains, with an explicit supported subset.

Scope

  • Reuse PropertyManifest, JsConcreteValue, the mapped entry-point bindings and the current machine initial-state mechanism.
  • Establish exact projection for booleans, bounded numeric inputs and supported primitive constants first. Add optional values, bounded tuples and bounded arrays only where the current heap/value representation supports them.
  • Publish a small per-domain table for strings, unbounded collections and every remaining common domain: supported representation, limits, and exact/approximate/unsupported status. A domain appearing in the common API does not require complete symbolic support here.
  • Respect JavaScript binary64, declared NaN/infinity/negative-zero policy, inclusive bounds, optional null versus undefined and argument order.
  • Execute supported pure preconditions according to #384. false discards the input; a thrown exception or invalid result is an error. Do not silently drop those errors or present solver UNKNOWN as UNSAT.
  • Report symbolic capability and derive concrete-only when the concrete backend supports an unsupported symbolic case.
  • For an approximate projection, state whether it adds values, omits values, does both, or has an unestablished relation to the declared domain. Replay is still required and unsuccessful search proves nothing.
  • Keep one capability decision path; do not duplicate domain definitions, value codecs or validators between the capability checker and projector.

Definition of Done

  • The documented exact subset instantiates inputs in the correct slots with satisfiable constraints matching the declared domains.
  • Focused conformance fixtures compare concrete accepted values with symbolic constraints, including boundary and special-value cases.
  • Preconditions follow the shared classification and purity contract.
  • Unsupported/approximate projections cannot be labeled exact.
  • Collection limits are explicit configuration/implementation limits, not silent truncation.
  • String support may remain approximate or unsupported; no full string solver or arbitrary object graph support is required.
  • Existing implementation work is reused and aligned with #384, with focused usvm-ts-pbt/usvm-ts checks.

Predicate violation targets, concrete replay and runtime-derived hints belong to later issues.

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 with PropertyManifest, JsConcreteValue, the mapped entry-point bindings, and the current machine initial-state mechanism. Review the shared-contract gate in #384 and the focused usvm-ts-pbt/usvm-ts checks before defining the supported projection subset. Done means satisfiable constraints match declared domains, preconditions follow the shared contract, and unsupported or approximate cases are explicitly reported rather than labeled exact.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, kotlin, typescript
Domain
compilers, testing
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.