Defect
Deslop reports its own crates/deslop-core/src/lang/ modules as a top-worst-band duplication family. These are false positives: the clusters are per-language constant tables, and there is nothing to extract.
| cluster id |
rank |
kind |
occurrences |
0aa0d20956d67315 |
4 |
nearly_identical |
lang/csharp.rs, lang/dart.rs, lang/rust_lang.rs |
b64bef9fb9aff7c9 |
7 |
loosely_similar |
lang/csharp.rs +4 |
257cc1642e1b6335 |
8 |
loosely_similar |
lang/csharp.rs +3 |
Why it is a false positive
0aa0d20956d67315 covers const BINDING_KINDS: &[BindingKind] plus const REFERENCE_TABLE: ReferenceTable in three language modules. The values are entirely disjoint — each names its own grammar's node kinds — and the arities differ (5 / 4 / 6 binding kinds; 6 / 3 / 5 skip_parent_kinds). The shared abstraction (BindingKind, ReferenceTable) is already extracted; what remains is per-language data that cannot be shared.
This is precisely the rationale [CLONE-NOISE-CONSTANT-TABLE] states:
A table of distinct named constants is data: there is no shared control flow and no abstraction to hoist, so there is nothing a reader could extract.
Why the filter misses it
cluster_filters/constant_table.rs requires every member's right-hand side to be a plain literal:
Any right-hand side that is not a plain literal — a call, a name, an attribute, an interpolated string — takes the member out of the shape and keeps the cluster visible.
Here the right-hand sides are const-constructor calls (BindingKind::new(...)) and a struct literal (ReferenceTable { ... }), so covers_only_constants returns false and the cluster survives. The narrowness is deliberate and documented, so this is a coverage gap rather than defective code — but the result is a false positive in the worst band, and it inflates duplicated_loc.
Suggested direction
Extend the constant-table shape to admit right-hand sides that are themselves const-evaluable data — const-fn constructor calls and struct/array literals over literals — while still requiring members to differ in raw bytes so a verbatim-copied table stays visible.
Defect
Deslop reports its own
crates/deslop-core/src/lang/modules as a top-worst-band duplication family. These are false positives: the clusters are per-language constant tables, and there is nothing to extract.0aa0d20956d67315nearly_identicallang/csharp.rs,lang/dart.rs,lang/rust_lang.rsb64bef9fb9aff7c9loosely_similarlang/csharp.rs+4257cc1642e1b6335loosely_similarlang/csharp.rs+3Why it is a false positive
0aa0d20956d67315coversconst BINDING_KINDS: &[BindingKind]plusconst REFERENCE_TABLE: ReferenceTablein three language modules. The values are entirely disjoint — each names its own grammar's node kinds — and the arities differ (5 / 4 / 6 binding kinds; 6 / 3 / 5skip_parent_kinds). The shared abstraction (BindingKind,ReferenceTable) is already extracted; what remains is per-language data that cannot be shared.This is precisely the rationale
[CLONE-NOISE-CONSTANT-TABLE]states:Why the filter misses it
cluster_filters/constant_table.rsrequires every member's right-hand side to be a plain literal:Here the right-hand sides are const-constructor calls (
BindingKind::new(...)) and a struct literal (ReferenceTable { ... }), socovers_only_constantsreturns false and the cluster survives. The narrowness is deliberate and documented, so this is a coverage gap rather than defective code — but the result is a false positive in theworstband, and it inflatesduplicated_loc.Suggested direction
Extend the constant-table shape to admit right-hand sides that are themselves const-evaluable data — const-fn constructor calls and struct/array literals over literals — while still requiring members to differ in raw bytes so a verbatim-copied table stays visible.