316c39ffe4
This PR fixes a `grind` congruence-table invariant violation that could panic when an `ite` branch was internalized lazily (after the condition became `True` or `False`) and that branch's equivalence class was later merged with another. `Internalize.lean` has a special case for `ite` that internalizes only the condition; the `then`/`else` branches are skipped and only internalized later on demand by `propagateIte`. The on-demand path (`applyCongrFun`) called `internalize` for the branch but never called `registerParent` to add the parent `ite` to the branch's parent set in the e-graph. Subsequent merges of the branch's equivalence class then skipped re-hashing the `ite` in the congruence table, leaving an orphan entry whose `congr` chain no longer matched the table's representative. The fix adds the explicit `registerParent e rhs` that the standard `for arg in args` loop in `Internalize.lean` would have made for an ordinary application argument; we are simply mirroring that pattern lazily. The same helper is reused by `propagateDIte`, but with parent registration disabled (controlled by a new `ite : Bool` parameter): for `dite` the `rhs` propagated upwards is a *constructed* reduction (built via `mkApp` from `e`'s children, possibly post-`preprocess`), not a structural argument of `e`, so registering `e` as its parent would be incorrect. The lambda branches of a `dite` are already eagerly internalized as parents of `e` by `Internalize.lean`, so this case does not need the fix. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 lines
97 B
Text
5 lines
97 B
Text
module
|
|
|
|
set_option grind.debug true in
|
|
theorem mwe2 (n : Nat) : [d][n]?.getD d = d := by
|
|
grind
|