Skip to content

Fix "Rule of same name exists already" error after pruning (rare but occuring cases after mass pruning with try-closeable-goals)#3850

Open
unp1 wants to merge 1 commit into
mainfrom
fix-prune-justification-leak
Open

Fix "Rule of same name exists already" error after pruning (rare but occuring cases after mass pruning with try-closeable-goals)#3850
unp1 wants to merge 1 commit into
mainfrom
fix-prune-justification-leak

Conversation

@unp1

@unp1 unp1 commented Jun 19, 2026

Copy link
Copy Markdown
Member

After using the Full-Auto-Macro where some proof goals remained open, I got an error "Rule of same name exists already ", when starting the proof search again.

The problem is a slight oversight in the proof pruner which misses to unregistered locally introduced rules at leaves. This fixes this rare but happening error. It also fixes a separate error that if at the cutting point a new taclet was registered, then this got lost.

Intended Change

Fix spurious double registration bug for taclets in \addrules

Type of pull request

  • Bug fix (non-breaking change which fixes an issue)
  • There are changes to the (Java) code

Ensuring quality

  • I made sure that introduced/changed code is well documented (javadoc and inline comments).
  • I added new test case(s) for new functionality. The added test fails on main and suceeds on this PR

Additional information and contact(s)

The contributions within this pull request are licensed under GPLv2 (only) for inclusion in KeY.

@unp1 unp1 self-assigned this Jun 19, 2026
@unp1 unp1 added the 🐞 Bug label Jun 19, 2026
@unp1 unp1 added this to the v3.0.0 milestone Jun 19, 2026
@unp1 unp1 changed the title Fix rule of same name exists already Fix "Rule of same name exists already" after pruning (rare but occuring cases after mass pruning with try-closeable-goals) Jun 19, 2026
When pruning a proof, taclets introduced locally (e.g. via \addrules) must
have their justification removed from the InitConfig. ProofPruner did this in
the breadth-first pass via visitedNode.parent().getLocalIntroducedRules(), but
locally introduced taclets are stored on the node at which they were
introduced, not on its parent. As a consequence a node's introduced rules were
only deregistered when one of its children was visited, so taclets introduced
at the leaf of a branch other than firstLeaf were never deregistered (firstLeaf
is handled separately by the child-to-parent traversal).

The leaked justification then collided with a freshly registered taclet of the
same name on the next automatic run, causing "A rule named ... has already been
registered" after Full Auto with try-close pruned closed branches.

Iterate the visited node's own getLocalIntroducedRules() instead, skipping the
cutting point itself (which survives the pruning). This also avoids the old
code's erroneous deregistration of the cutting point's parent's rules.
@unp1 unp1 force-pushed the fix-prune-justification-leak branch from 06662d2 to 58e6c36 Compare June 19, 2026 19:57
@unp1 unp1 enabled auto-merge June 19, 2026 20:14
@unp1 unp1 changed the title Fix "Rule of same name exists already" after pruning (rare but occuring cases after mass pruning with try-closeable-goals) Fix "Rule of same name exists already" error after pruning (rare but occuring cases after mass pruning with try-closeable-goals) Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant