juli/OrcaSlicer
1
1
Fork 0
mirror of https://github.com/OrcaSlicer/OrcaSlicer.git synced 2026-09-22 00:12:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

CAD: undo() never rolled back variables, so a bad one bricked the recipe

Browse Source 
checkpoint() snapshotted `features` and undo() restored `features`, but
`variables` is a separate member of CadDocument. Every caller of the documented
checkpoint -> mutate -> recompute -> undo-on-failure pattern therefore failed to
roll a variable back: the bad value stayed in the document and every later
recompute failed, which is exactly the corruption the pattern exists to prevent.
Feature `expr` bindings were unaffected only because expr lives inside
CadFeature and rode along in the features snapshot — which is why the feature
side appeared to work.

This was a kernel gap, not a GUI one: McpControl::action_set_variable has the
same sequence and was equally broken.

The undo/redo stacks now hold a {features, variables} Snapshot. Nothing here is
serialized, so no recipe version change and no golden-fixture regeneration.

Two tests, both verified to FAIL against a faithful reproduction of the bug
(undo() leaving `variables` untouched) at test_caddocument.cpp:4420 and :4441:
one covers restoring a variable's previous value, the other covers removing a
variable that did not exist before the checkpoint. Worth recording that the
first mutation attempt was NOT faithful — it dropped the restore but kept
std::move(variables) into the redo stack, which empties the map as a side effect
and made the second test pass for the wrong reason. A mutation has to reproduce
the original defect, not merely break the code.

Second defect, same area: undo() calls recompute(), which succeeds and clears
doc.error, so the reason an edit was rejected was destroyed before anything
could display it. Six sites — four in DesignPanel, two in McpControl — now carry
the message across the rollback. on_remove_variable additionally asserted
"referenced by a feature expression" as fact; it now offers that as the likely
cause and appends the real error, since that diagnosis is wrong for any other
failure.

Suite 141 cases / 1972 assertions (was 139/1960). GUI compiles clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Tommaso Bianchi
2026-07-25 23:56:34 +02:00
co-authored by Claude Opus 5
parent 33275f2c74
commit c565d6ba86
5 changed files with 94 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/slic3r/GUI/McpControl.cpp
+6 -2
View File
@@ -1372,7 +1372,9 @@ json action_set_variable(DesignPanel* panel, const json& params)
doc.checkpoint();
doc.variables[name] = expr;
bool ok = doc.recompute();
if (!ok) { doc.undo(); }
// undo() recomputes, which succeeds and clears doc.error; carry the reason across so
// the JSON reply below reports why the edit was rejected instead of an empty string.
if (!ok) { const std::string why = doc.error; doc.undo(); doc.error = why; }
panel->mcp_after_change();
return json{{"ok", ok}, {"name", name}, {"error", doc.error}};
}
@@ -1392,7 +1394,9 @@ json action_set_feature_expr(DesignPanel* panel, const json& params)
doc.checkpoint();
doc.features[fi].expr[field] = expr;
bool ok = doc.recompute();
if (!ok) { doc.undo(); }
// undo() recomputes, which succeeds and clears doc.error; carry the reason across so
// the JSON reply below reports why the edit was rejected instead of an empty string.
if (!ok) { const std::string why = doc.error; doc.undo(); doc.error = why; }
panel->mcp_after_change();
return json{{"ok", ok}, {"feature", fi}, {"field", field}, {"error", doc.error}};
}