[parthod0x]

Fixes #603.

Subtype checking was O(depth²) on nested types. Type derives a deep
structural PartialEq, and subtype_ / subtype_collect_ used
if t1 == t2 as a per-level short-circuit — so the deep compare re-ran at
every recursion level, re-traversing the surrounding structure each time
(vec^d(leaf) → O(d) + O(d−1) + … = O(d²)). That == is also load-bearing
for correctness: it is the only source of reflexivity for base types that
have no structural subtype arm, so it cannot simply be removed.

Fix

• Add same_type_fast(t1, t2): Rc::ptr_eq fast-accept, then for leaves
  (and Var/Knot) an O(1) leaf == t2 check, while composites return
  false so the existing structural arms descend one level — no deep
  re-traversal. It only ever returns true when == would, so it is sound.
• Use same_type_fast for the per-level short-circuit in subtype_ and
  subtype_collect_.
• Keep a single deep if t1 == t2 { return } at the public entry points
  (subtype_with_config, subtype_check_all), before allocating
  Assumptions — so a wholly-equal pair is still decided in one linear pass
  and never enters the recursion.

This differs from the same_type_fast sketch in the issue thread, which
dropped the top-level deep ==: separately-allocated-but-equal composite
trees then fell through into the full structural recursion and regressed
3.8–6.9×. Restoring the single top-level == keeps the large unequal-case
speedups and avoids that equal-case regression. The decode data path
(de.rs → subtype_with_config) benefits from both.

Benchmark (examples/subtype_bench.rs, median ns/op/depth)

vec^d(leaf), depths 16–512, asserting the verdict on every run:

case	before (d512)	after (d512)	shape
widening (succeeds)	607,669 ns	19,499 ns	ns/op/depth 1187 → ~38 (flat = linear), ~31×
rejection (fails at leaf)	603,823 ns	17,001 ns	1179 → ~33 (flat), ~36×
equal, separately allocated	2,053 ns	~2,543 ns	stays flat ~5 ns/op/depth = still the single-pass path, no regression

(Absolute timings are noisy — the machine was under full CPU load — but the
ns/op/depth shape is the signal: before grows with depth, after is flat.)

Tests

• cargo test -p candid: 130 passed, 0 failed (subtype_assumptions,
  subtype_lookup, subtype_recursion_limit all green).
• cargo clippy -p candid --all-targets -- -D warnings: clean.
• Verified on the host target; CI will exercise the wasm32 build/bench. Happy
  to also port the repro into rust/bench as a canbench case if you'd like
  the speedup reflected in CI bench output.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to ca4c02b.

Security Overview

• 🔎 Scanned files: 3 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/7ddf29dd-76dc-4f78-adfa-47ac8f4643e7?scanId=e6bfcbc0-badb-4585-be74-feb43fc01107&codeScanTypes=PrScan&tab=issues&detectionTypes=traditional,businessLogic,customRule,IAC,SECRETS,CICD,EOL,uncategorized

Detected Code Changes

Change Type	Relevant files
Enhancement	► rust/candid/examples/subtype_bench.rs     Add micro-benchmark for deep subtype traversal (#603)
Enhancement	► rust/candid/src/types/subtype.rs     Introduce memoized deep equality and per-type pointer identity cache to address quadratic subtype traversal (#603)
Enhancement	► rust/candid/tests/subtype_equal_subtree.rs     Add tests for equal subtree handling under recursion guard (#603)

[cla-idx-bot]

Dear @parthod0x,

In order to potentially merge your code in this open-source repository and therefore proceed with your contribution, we need to have your approval on DFINITY's CLA.

If you decide to agree with it, please visit this issue and read the instructions there. Once you have signed it, re-trigger the workflow on this PR to see if your code can be merged.

— The DFINITY Foundation

[Copilot]

🟡 Changes recommended

Valid subtype checks can now fail with recursion-limit errors on deeply nested equal subtrees, including trees reached through different aliases in both subtype APIs.

1 open issue

• Avoid recursion-limit errors for equal deep subtrees · New

What changed in this PR

Addresses #603 by removing repeated deep equality comparisons from Candid’s recursive subtype checks while retaining a fast path for wholly equal types.

Changes:

• Adds pointer and leaf equality checks within both subtype implementations.
• Keeps one deep equality check at each public entry point.
• Adds a microbenchmark for widening, rejection, and separately allocated equal types.

File	Description
rust/​candid/​src/​types/​subtype.rs	Replaces per-level deep equality with a lightweight check.
rust/​candid/​examples/​subtype_bench.rs	Measures subtype-checking performance across increasing nesting depths.

_{Review effort: Balanced}

[parthod0x]

Good catch — both cases were real. Fixed in fbd60df.

The per-level reflexivity check inside the recursion was a bare ptr_eq/leaf test. It's O(1), but it stops recognising separately-allocated equal composite subtrees. When such a subtree's parents differ — so the entry-point whole-type == can't fire — it was walked level by level into the depth guard, so a valid, reflexive check could return "recursion limit exceeded". The alias case is the same gap reached through two different Var names.

Fix: the per-level check is a deep structural equality again — it returns exactly what t1 == t2 would, so the acceptance is restored — but it's memoized by pointer identity, so each subtree pair is compared at most once across the whole check. That keeps #603's de-quadratic behaviour. The benchmark gains a subtree row for exactly this shape (record { 0: vec^d nat; 1: nat } <: record { 0: vec^d nat }), and it stays linear in depth:

## subtree   record{vec^d nat; nat} <: record{vec^d nat}
 depth |          ns/op |    ns/op/depth
    16 |         3306.6 |        206.661
   128 |        16544.9 |        129.257
   512 |        49531.3 |         96.741

Verification:

• An inline oracle test asserts same_type agrees with the derived == across leaves, records, variants, funcs, services, classes and nested composites, so the memoized walk can't drift from ==.
• Small-stack integration tests (tests/subtype_equal_subtree.rs) check that a deep equal subtree under differing parents, and one reached through two different aliases, is accepted at a depth where a mismatched chain of the same depth does hit the limit. Both assertions fail on the pre-fix check and pass now.
• The memo's keys are pinned alive for the duration of the check, so a freed address can't be reused under a live key.
• cargo test -p candid, cargo clippy -p candid --all-targets (no warnings) and cargo fmt --check are all green.

[Copilot]

🟡 Changes recommended

The equality fallback caches only outer function/service type pairs, leaving nested descendants uncached and causing O(depth²) equality work during subtype checks.

1 open issue

• Cache nested Func and Service comparisons · New

1 resolved since last review

• Avoid recursion-limit errors for equal deep subtrees

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The recursive same_type traversal bypasses the recursion-depth guard and can overflow the stack and abort the process in both subtype APIs when comparing deep equal subtrees beneath unequal record parents.

1 open issue

• For a deep, separately allocated equal subtree beneath unequal record parents, same_type can… · New

1 resolved since last review

• Cache nested Func and Service comparisons

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

When stack size cannot be detected, the calibration leaves insufficient depth budget for enclosing record and alias-resolution frames, causing both acceptance tests to exceed the 512-depth guard and fail.

1 open issue

• Fallback stack limit is too small for equality acceptance tests · New

1 resolved since last review

• For a deep, separately allocated equal subtree beneath unequal record parents, same_type can…

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human review is needed to assess how equality probing interacts with the shared recursion guard and can incorrectly reject valid subtype relations.

No open issues 🎉

1 resolved since last review

• Fallback stack limit is too small for equality acceptance tests

_{Review effort: Balanced}

[parthod0x]

Summary for review — the automated passes are now clean (no open issues), and the latest Copilot note correctly defers one point to human judgment: how the reflexive-equality fast path (same_type) should interact with the shared recursion guard. Worth stating the trade-off explicitly since it's a design choice, not an accident.

What this PR does. subtype ran a deep structural t1 == t2 at every recursion level (#603), which is O(depth²). It's now replaced by same_type, a pointer-memoized deep equality that returns exactly what == would but compares each subtree pair at most once, so the per-level check is O(1)-amortized. Func/Service recurse through it like the other composites, and it shares the structural RecursionDepth.

The trade-off (the point Copilot flags for a human). Because same_type now shares the recursion budget, a reflexively-valid relation whose equal subtree is deeper than the budget is reported as Recursion limit exceeded — the same limit the structural rules already impose on every other too-deep type — rather than being accepted. The two coherent options:

1. (this PR) Respect the shared limit. One recursion bound for all paths; a too-deep type is rejected uniformly and nothing can overflow the native stack. Simple and consistent with how subtype already treats depth. Cost: an equal subtree deeper than the limit is rejected even though it is reflexively a subtype.
2. Let equality transcend the limit via an explicit heap-backed worklist, so arbitrarily deep equal subtrees are accepted without recursing. More permissive, but a second traversal mechanism alongside the existing guarded recursion, and only for the reflexive case.

I went with (1) as the smaller, more consistent change — candid already rejects over-deep types by design (utils::check_recursion_depth), so applying the same bound to the equality shortcut keeps one policy and removes the unguarded stack-overflow path entirely. Happy to switch to (2) if you'd rather deep equal types always be accepted; it's a self-contained follow-up.

Behaviour within the limit is unchanged (the oracle test pins same_type ≡ ==), and the deep-recursion tests cover both the accept case (equal subtree just under the limit) and graceful failure well past it, in both the stack-measured and the fixed-512-count guard modes.