Catalog coverage by dimension¶
Phase 6 of the examples/catalog split (retired plan record; see plans/index.md): the calibration catalog under examples/ is 208 caseNN_* fixtures, but not 208 independent ABI/API concepts -- several are variants of the same rule, or scenarios composing rules already counted elsewhere. This page reports the catalog along five independent dimensions instead of one flat case count, so "three demonstrations of one rule" reads as "1 rule, 3 cases (1 canonical + 2 variants)" rather than "3 ABI concepts". Regenerate with python scripts/gen_catalog_coverage_report.py after any ground_truth.json, catalog/taxonomy.json, or catalog/catalog_classification.yaml change.
Rule coverage¶
Every rule named below is defined in catalog/catalog_rules.yaml, the canonical rule registry (a repository file, not a published page). A slug used by a case but missing from that file (or defined there but used by no case) fails scripts/gen_catalog_taxonomy.py and tests/test_catalog_taxonomy.py -- which is what stops a typo, a synonym, or an accidental rename from silently becoming one more "distinct compatibility rule" in the headline below.
- 188 distinct compatibility rules in total -- 171 demonstrated by at least one rule-entity case (across 178 rule-entity cases), plus 17 named only in a scenario's own
related_rules(a generic mechanism no single-library case demonstrates alone yet). The two are not equivalent coverage: a referenced-only rule has a definition and a scenario that composes it, but no case that isolates it. - 5 of the demonstrated rules have a variant beyond their canonical case -- a genuine robustness demonstration under a different condition (5 variant cases total -- see the per-family breakdown below); these are robustness demonstrations of an already-counted rule, not additional rules.
- 2 of the demonstrated rules also have a duplicate -- the same demonstration restated with no distinguishing condition (2 duplicate cases total); these don't add robustness coverage and are candidates for eventual removal, not a variant to keep. (A family can appear in both this count and the variant count above if it has one of each.)
- 164 demonstrated rules have exactly one case so far, with no variant or duplicate yet.
| Rule | Canonical case | Variant case(s) | Duplicate case(s) |
|---|---|---|---|
embedded-type-size-increased |
case07_struct_layout |
case14_cpp_class_size |
|
enum-member-value-changed |
case08_enum_value_change |
case20_enum_member_value_changed |
|
executable-stack-flag-changed |
case49_executable_stack |
case136_executable_stack_removed |
|
exported-function-removed |
case01_symbol_removal |
case12_function_removed |
|
inline-function-outlined |
case16_inline_to_non_inline |
case47_inline_to_outlined |
|
public-api-gains-internal-dependency |
case160_public_api_internal_dep_added |
case190_public_inline_function_references_internal_constant |
|
symbol-version-node-removed |
case65_symbol_version_removed |
case139_symbol_version_node_removed |
Referenced-only rules¶
17 rules the catalog names but does not yet isolate in a case of its own. Each is a real compatibility mechanism a scenario composes; adding a rule-entity case whose rule_slug is one of these promotes it to demonstrated automatically, with no registry edit.
| Rule | Composed by |
|---|---|
audit-public-not-exported |
case150_xcheck_export_public_pair |
compatible-type-added |
case108_task_class_removed, case109_flow_graph_policy_renames, case191_header_only_graph_field_type, case78_task_arena_attach_tag |
constructor-overload-ambiguity |
case111_enumerable_thread_specific_lambda_ambiguity |
empty-tag-type-gains-state |
case94_empty_tag_gained_state |
exported-type-removed |
case107_task_scheduler_init_removed, case108_task_class_removed, case78_task_arena_attach_tag, case82_sycl_overload_set_removed |
header-build-context-mismatch |
case148_xcheck_header_build_mismatch |
internal-declaration-identity-reconciled |
case197_header_graph_identity_reconciled |
internal-declaration-moved-reconciled |
case196_header_graph_move_reconciled |
internal-declaration-renamed-reconciled |
case194_header_graph_rename_reconciled |
internal-symbol-required-by-public-api |
case192_call_graph_break_survives_suppression |
odr-type-variant |
case149_xcheck_odr_variant |
overload-set-removed |
case82_sycl_overload_set_removed |
public-class-representation-changed |
case126_sycl_device_impl_ptr |
public-integer-model-width-changed |
case112_lp64_ilp64 |
symbol-export-namespace-changed |
case176_kabi_symbol_namespace_changed |
symbol-type-signature-hash-changed |
case175_kabi_crc_changed |
virtual-dispatch-contract-removed |
case108_task_class_removed |
Scenario coverage¶
30 scenario-entity cases composing one or more rules into a realistic problem (an ecosystem case study, a multi-library project topology, or a capability/evidence demonstration) -- see each case's own related_rules.
| Scenario kind | Cases |
|---|---|
capability |
12 |
case-study |
13 |
project-topology |
5 |
Ecosystem coverage¶
Every case, rule or scenario, tagged with the real-world ecosystem it models (generic for a language/platform-level mechanism with no particular project behind it).
| Ecosystem | Cases |
|---|---|
generic |
195 |
linux-kernel |
3 |
onemkl |
1 |
onetbb |
7 |
sycl |
2 |
Workflow coverage¶
7 workflow examples so far, out of the 7 task-oriented workflows Phase 5 of the examples/catalog split (retired plan record; see plans/index.md) targets: compare one library, audit a release, multi-library project, evidence depth (including build/source evidence), Python API, suppressions, GitHub Actions.
| Workflow | Task | Platforms | Executed steps |
|---|---|---|---|
audit-release |
Did I accidentally ship an undocumented export consumers could start depending on? | linux, macos | 2 |
compare-project |
Did removing a function from one library in my project break a sibling library that depends on it? | linux, macos | 6 |
compare-release |
Did my next release break anything for existing consumers? | linux, macos | 3 |
evidence-depth |
What does the evidence I give abicheck actually let it see, and what does each additional layer add? | linux, macos | 7 |
github-actions |
How do I run this check automatically on every pull request, without anyone remembering to run it (or writing a CI script myself)? | linux, macos | 3 |
python-api |
I want to run this check from my own build script or test suite, not by shelling out to the CLI -- how do I call abicheck from Python? | linux, macos | 3 |
suppressions |
I renamed a function on purpose -- how do I stop CI from failing on it, without turning off detection for everything else? | linux, macos | 4 |
Each row is a workflow.yaml that validation/scripts/run_workflow_examples.py runs end to end -- the documented commands themselves, in a scratch copy, checked against the exit code and the verdict/change kinds the walkthrough claims. A directory without that contract is a hard error rather than a free point of coverage.