Skip to content

blockifier_test_utils: delete dead code (unsure, review carefully) - #14881

Open
asaf-sw wants to merge 1 commit into
mainfrom
code_slayer/remove_dead_code_in_blockifier_test_utils
Open

blockifier_test_utils: delete dead code (unsure, review carefully)#14881
asaf-sw wants to merge 1 commit into
mainfrom
code_slayer/remove_dead_code_in_blockifier_test_utils

Conversation

@asaf-sw

@asaf-sw asaf-sw commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

Caution

REVIEW WITH CARE! THIS PR REQUIRES CAREFUL HUMAN REVIEW.
If you find this to be a false positive comment in detail why this code should be kept and close the PR.

What

Removes two unused pub fn helpers from blockifier_test_utils and their now-orphaned imports:

  • FeatureContract::all_cairo1_casm_compiler_versions (contracts.rs) and the use std::collections::HashSet; it was the sole user of.
  • cairo1_compiler_tag (cairo_compile.rs) and the use apollo_infra_utils::cairo_compiler_version::CAIRO1_COMPILER_VERSION; import it was the sole user of. (That symbol is still used elsewhere in contracts.rs:310, so the import there is retained.)

Why these look dead

A workspace-wide grep for each identifier finds only the definition site — no callers in any crate, in tests//benches/, or in the sibling repos starkware-industries/sequencer-devops and starkware-industries/starkware. Both are inherent pub fns (not behind a trait, macro, serde, FFI, or reflection), so a textual grep fully captures their references.

What a human must verify

blockifier_test_utils is a test-utility crate whose pub fns form its public API. These two have no in-workspace or sibling-repo callers, but I cannot rule out an external consumer (e.g. another repository's test harness) that depends on cairo1_compiler_tag or all_cairo1_casm_compiler_versions. Please confirm no out-of-tree consumer relies on them before merging.

Verification (local)

Env workarounds applied (RUSTC_WRAPPER=, CARGO_INCREMENTAL=0):

  • cargo build -p blockifier_test_utils — clean, zero warnings.
  • cargo build -p blockifier_test_utils --tests — clean, zero warnings.
  • cargo clippy -p blockifier_test_utils --all-targets — clean.
  • SEED=0 cargo test -p blockifier_test_utils — all tests pass.

Caution

REVIEW WITH CARE! THIS PR REQUIRES CAREFUL HUMAN REVIEW.
If you find this to be a false positive comment in detail why this code should be kept and close the PR.


Generated by Claude Code

Removes two unused `pub fn` helpers and their now-orphaned imports:

- `FeatureContract::all_cairo1_casm_compiler_versions` (contracts.rs) and the
  `use std::collections::HashSet;` it was the sole user of.
- `cairo1_compiler_tag` (cairo_compile.rs) and the
  `use apollo_infra_utils::cairo_compiler_version::CAIRO1_COMPILER_VERSION;`
  import it was the sole user of (that symbol is still used elsewhere in
  contracts.rs, so its import there is retained).

Evidence of deadness: a workspace-wide grep for each identifier finds only the
definition site -- no callers in any crate, in `tests/`/`benches/`, or in the
sibling repos `starkware-industries/sequencer-devops` and
`starkware-industries/starkware`. These are inherent `pub fn` (not behind a
trait, macro, `serde`, or reflection), so grep fully captures their references.

Verification (env workarounds: `RUSTC_WRAPPER=`, `CARGO_INCREMENTAL=0`):
- `cargo build -p blockifier_test_utils` -- clean, zero warnings.
- `cargo build -p blockifier_test_utils --tests` -- clean, zero warnings.
- `cargo clippy -p blockifier_test_utils --all-targets` -- clean.
- `SEED=0 cargo test -p blockifier_test_utils` -- all tests pass.

Filed as low-confidence: `blockifier_test_utils` is a test-utility crate whose
`pub fn`s form its public API. They have no in-workspace or sibling-repo callers,
but I cannot rule out an external consumer (e.g. another repo's test harness)
depending on them, which is the reachability uncertainty a human owner must
adjudicate.
@reviewable-StarkWare

Copy link
Copy Markdown

This change is Reviewable

@asaf-sw
asaf-sw requested a review from Yoni-Starkware July 25, 2026 06:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants