Hazel reports · ^report(26) · review · started 2026-10-22 · work in progress · about 4 minutes to read

Does #2681 Need #2661?

Alexander, on #2681 (a value known to have a type is not walked again for it): Looks like it needs #2661 as a dependency. Might be worth just changing the parent branch of the pr to that branch. Matthew: It seems like a real dep, but I'll double check. This is that double check (^ticket(541)), made with git alone, nothing built or run.

Short answers.

  1. Yes, #2661 is a real dependency. #2681's own commit, 8546bde64e, keys its memo by the type's hash: known_to_have and noted both call TypHash.hash(t), which #2661 adds. Without #2661, #2681 does not compile.
  2. #2681 carries #2661 today as merges, not as a base. Its branch merged #2661's first two commits (0875dfcd66, 67f676852b) and #2679 (a032bd5c6a), and holds a copy of #2661's third (a4fee77a63, the same patch as #2661's 09b8af372f). So against dev its diff is 39 files, the dependencies included, and it is 14 commits behind dev.
  3. Retargeting works, after one merge. #2661's branch is up to date with dev (it merged dev, which now has #2679). Merging #2661's head into #2681's branch conflicts in Ascriptions.re, the known conflict between #2661's and #2679's helpers, and #2681's side is the right resolution: it already has both helpers and the memo. After that merge, #2681 against #2661's branch is 4 files, +161 and -2: its own commit, one line of layout apart.
  4. So Alexander's suggestion is the simplest review. Merge #2661's head into #2681's branch (resolution: #2681's Ascriptions.re), push, and set #2681's base to typ-hash-consistent. Reviewers see one commit. When #2661 lands, #2681's base goes back to dev and its diff stays that one commit.

The evidence#

What #2681's commit uses from #2661#

known_to_have = (d, t) => switch (type_key(d), TypHash.hash(t)) { ... }
noted = (e, t, r) => switch (r, TypHash.hash(t)) { ... }
let has_type: Util.IdentityTable.t(Obj.t, list(TypHash.t))

The memo remembers, per value, the hashes of the types it has; a lookup asks for the type's hash. TypHash is #2661's module, so the dependency is in the memo's design, not incidental.

The branches today#

branchheadagainst dev
#2661, typ-hash-consistent09b8af372f4 commits ahead (its three, and a merge of dev), 0 behind
#2681, ascriptions-has-typea4fee77a636 commits ahead (#2661's first two, a merge of #2679, its own 8546bde64e, a merge of #2661's three-lane hash, a copy of #2661's test commit), 14 behind

a4fee77a63 on #2681 and 09b8af372f on #2661 have the same patch (git patch-id), so the merge below takes it once.

The retarget, simulated#

In a scratch worktree, never pushed: #2681's head, merged with #2661's head.

The steps#

  1. On ascriptions-has-type: git merge origin/typ-hash-consistent; resolve Ascriptions.re with #2681's side; build and run Ascriptions, TypHash and Evaluator (on GitHub's CI).
  2. Push, then set #2681's base to typ-hash-consistent. The PR then shows one commit.
  3. Optionally, in the same push: the depth-1 limit on the memo and its test (proposed on #2681, measured in ^report(25)).
  4. When #2661 merges into dev, set #2681's base back to dev (GitHub does it on its own if #2661's branch is deleted).

How this was put together#

git on dev at 962a7cb009, #2661 at 09b8af372f and #2681 at a4fee77a63, 2026-10-22: git log per branch, git merge-base --is-ancestor per commit, git patch-id for the copied commit, and the merge in a scratch worktree (resolution recorded, nothing pushed). The stats are in data/.

The data#