Dead code removal - #38166
Draft
def- wants to merge 13 commits into
Draft
Conversation
`ordering.rs` contained only a license header and a doc comment describing transformations that impose a canonical order on the inputs of multi-input relation expressions. No code was ever added, and `pub mod ordering;` was its only reference in the tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
None of these modules had a single reference outside their own file, verified symbol by symbol across the workspace: * `graph` (235 lines) exposed four non-recursive depth-first traversal helpers. Its original caller is gone; since then it has only been touched by mechanical lint sweeps. * `permutations` exposed `argsort` and `inverse_argsort`, plus `invert`, which was used only by `inverse_argsort` inside the module. The similarly named `join_permutations` and `permutation_for_arrangement` in `mz-expr` are unrelated code and stay. * `hash` exposed a one-line `DefaultHasher` wrapper. Call sites that look like it use `seahash::hash` instead. * `bits` exposed `align_up`, added for linker-supplied build IDs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
`mz-s3-datagen` generated test data in S3. Nothing depends on it: no reverse dependency in any manifest, no mzbuild image, no CI step, no Dockerfile, and no `bin/` wrapper. Its only mentions were the two workspace member lists and its own manifest. Removing it orphans the `bytefmt` workspace dependency, which had no other user, so that goes too. The Cargo.lock diff is limited to those two packages. `doc/developer/generated/s3-datagen/` still exists. That tree is owned by the docs agent, so it is left for the `update-docs` workflow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
These four flags were defined in `vars/definitions.rs` but no Rust code ever read them, so they were live `ALTER SYSTEM SET` knobs that silently did nothing: * `enable_multi_worker_storage_persist_sink` * `enable_persist_streaming_snapshot_and_fetch` * `enable_persist_streaming_compaction` * `enable_off_thread_optimization` Removing a system variable is safe for existing catalogs. Nothing deletes stale values from durable storage, but both boot paths already tolerate them and log a warning instead of failing, at `catalog/open.rs` for defaults and `catalog/apply.rs` for the durable collection. Of the four, only `enable_multi_worker_storage_persist_sink` exists in LaunchDarkly, so it moves to `KNOWN_STALE_LD_FLAGS`. The other three were already in `KNOWN_MISSING_FROM_LD` and those entries go away with them. The mzcompose override that force-enabled the first flag in CI is dropped too, since nothing consumed it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
Seven write methods on the durable `Transaction` had no callers. Each name occurred exactly once in the workspace, at its own definition: * `insert_system_schema` * `update_introspection_source_index_gids` * `allocate_user_item_ids` * `remove_database` * `remove_schema` * `update_system_object_mappings` * `set_replicas` The plural `remove_databases` and `remove_schemas` are live and stay. `USER_ITEM_ALLOC_KEY` was left imported only for the test module, which picks it up through `use super::*`, so the import moves there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
None of these are reachable from any entry point. Reachability was computed as an import graph over every tracked `.py`, seeded from the `-m` targets in `bin/` and `ci/`, every `mzcompose.py`, and the glob-plus-`__subclasses__` discovery used by the check and benchmark suites, then confirmed per module by grep. * `teleport.py` and `build_config.py` import each other and nothing else imports either. The many `materialize.teleport.sh` hits in the console tree are hostnames, not this module. * `query_fitness/` is a self-contained package whose only references are internal. * `mzcompose/services/squid.py` defines a forward-proxy service that no composition instantiates, and its default mount points at a `squid.conf` that does not exist anywhere in the repo. * `setup.py` is a setuptools shim for shipping the `materialize` package into cloudtest images. No Dockerfile installs it, and `ci/deploy/pypi.py` only handles `misc/dbt-materialize`. * The remainder are small orphans: `uuid_operation_param`, `test_analytics_setup`, `buildkite_insights/segfaults/`, `print_query_result`, `param_matchers`, and `sandbox_db_config`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
`toxiproxy.py` stays: `ToxiproxyDeployment` and `ToxiproxyService` are used by `test/cloudtest/test_privatelink_connection.py`. But three top-level symbols below them each occurred exactly once in the tree, at their own definition, and go: * `toxiproxy_resources`, a convenience constructor for the two live classes that no caller ever used * `PrivateLinkTestRedpandaDeployment` * `PrivateLinkTestRedpandaService` Removing them orphans the `DEFAULT_K8S_NAMESPACE`, `K8sResource` and `REDPANDA_VERSION` imports, which go with them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
Two manifest defects, both harmless to the build but confusing to
tooling:
* `src/materialized` was listed twice in the root `[workspace] members`
block. Cargo deduplicates, so this was purely a copy-paste artifact.
It is still listed once in `default-members`, which is separate and
correct.
* `src/balancerd/Cargo.toml` declared `mz-dyncfg-file= { ... }` with no
space before the equals sign. Valid TOML, but it hides the dependency
from any tooling that matches on `^name =`, which is exactly what made
`mz-dyncfg-file` look like an orphaned crate during this audit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
Materialize has not shipped a `.deb` in years and none of this is referenced from anywhere in the tree: * `misc/dist/` holds a systemd unit and a `deb-scripts/postinst`, last touched in 2022 when `--log-file` was removed. * `misc/python/materialize/deb.py` is the matching Python helper, with no importer. * `misc/tb/` contains a single README whose first line reads "tb is no longer maintained", pointing at an archived repository. The directory has held nothing else since the 2021 commit that removed the source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
A workspace-wide sweep for functions whose name occurs exactly once in
the tree, at their own definition. The compiler's `dead_code` lint stops
at the crate boundary, so a `pub fn` in a library crate looks used to
rustc even when nothing in the workspace calls it. These 29 did not:
adapter with_debug_in_bootstrap, allocate_system_id,
find_available_cluster_name,
get_mz_catalog_server_cluster_id,
get_system_configuration, is_synchronized,
clear_transaction_ops, new_from_parts, lag_from
expr make_nonrecursive, debug_size_and_depth, replace_using
repr with_columns, try_pack, dot_string_at, month_multiplier
persist get_or_make_codec, is_structured
sql allocate_resolved_item_name
storage set_records_indexed, set_bytes_indexed
and singles in controller, http-util, arrow-util, transform,
timely-util, ore, and sql-server-util.
Removing them exposed a second layer that the compiler could then see:
`scalar_to_arrow_datatype` in mz-arrow-util and `try_from_sql_server` in
mz-sql-server-util, the latter reachable only from the
`get_transaction_isolation` removed above. Both go too, along with the
imports all of this orphaned.
`modify_dependency_item_ids` in `sql/src/names.rs` matched the same
"referenced once" heuristic but is a trait method, reached through the
trait rather than by name, so it stays.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
* `package-lock.json` at the repo root locks nothing: its `packages` object is empty and there is no root `package.json` to go with it. It was committed by accident in ee0abfa and no CI script, Dockerfile, or dependabot entry references it. The `package-lock.json` in `misc/vscode-ext/.vscodeignore` is that extension's own file, not this one. * `console/public/logo.png` is referenced nowhere. `public/` is copied verbatim into `dist/`, so it was shipping to production unused. * The three social marks under `console/img/` are referenced nowhere. Every other image in that directory is explicitly imported by `integrationsList.ts` or the environment-not-ready components. `console/src` contains no `import.meta.glob` or `require.context`, and no CSS `url()` outside `font/inter.css`, so nothing here is reachable by a dynamically constructed path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
Nineteen files that nothing imports. Reachability was computed three ways and the results agreed: `knip` with an explicit entry list, a custom import graph resolving `~/` aliases and dynamic `import()`, and per-file grep for import specifiers. Almost all of them arrive from 4ed78af, "Restore console, was removed in MaterializeInc#34933". That bulk restore brought back modules nothing was rewired to use. `api/materialize/useShowCreate.ts` is the clearest case: it is a duplicate of the live `queries/showCreate.ts`, which is what `ShowCreateBlock.tsx` actually calls. `platform/auth/utils.ts` had exactly one importer, `PasswordField.tsx`, which is itself in this list, so the two come out together. `theme/components/IconButton.ts` is not re-exported by `theme/components.ts`, unlike its twenty siblings, so the namespace spread in `theme/index.tsx` never picks it up. Note on method: run without a config, knip reports 243 unused files, including every test and all of `e2e-tests/`. That is an artifact of it failing to load `vitest.config.ts` and `playwright.config.ts` to discover test entry points. The real figure is the one above. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
`mz-durable-cache` declared 17 dependencies. Ten of them do not appear anywhere in its only source file, a 539-line `lib.rs`: `async-trait`, `bytes`, `futures`, `itertools`, `mz-dyncfg`, `mz-timely-util`, `prometheus`, `prost`, `serde`, and `uuid`. Also removes three entries from `[workspace.dependencies]` that no member crate references at all: `digest`, `httparse`, and `subtle`. Unreferenced workspace entries cost no compile time, but they are dead config that misleads version audits. NOTE: the project's own `bin/unused-deps` does not catch any of this. On the current nightly, `cargo udeps` reports "All deps seem to have been used" for the whole workspace, including this crate. The `-Z binary-dep-depinfo` mechanism it relies on lists every `--extern` whether or not rustc loaded it, so the check passes unconditionally and provides no signal. Verified by a full `cargo check --workspace --all-targets` instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L6oPKaHDfKY9uk19kRofVA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.