Analyzer drops the `add ... to CONST` report when combined with other constant mutations

[logbie]

Found while converting syntax_test/test_constant_immutability.wfl into the asserted diagnostics fixture tests/fixtures/diagnostics/constant_immutability.wfl (repository hygiene migration).

Each mutation form (change, add, subtract, multiply, divide) is correctly rejected with Cannot modify constant ... when it appears alone. But when several mutations of the same constant appear in sequence, the analyzer emits only 4 reports for 5 mutations — the add 10 to MAX_SIZE report is the one dropped (verified by removing each line in turn: removing the add line still yields 4 reports; removing any other line yields 3).

Repro (exit code 3, count the reports):

store new constant MAX_SIZE as 100
change MAX_SIZE to 200
add 10 to MAX_SIZE
subtract 5 from MAX_SIZE
multiply MAX_SIZE by 2
divide MAX_SIZE by 2

tests/diagnostics_fixtures_test.rs::constant_mutation_is_rejected_for_every_mutation_form currently pins >= 4 reports with a comment pointing here; tighten it to >= 5 when this is fixed.

[logbie]

Fixed on branch claude/issue-671-8ufs93 (commits 1be7188 Red, 29c9ddf Green).

Root cause

The report was never dropped — it was never produced for add in the first place.

change, subtract, multiply, and divide all desugar to Statement::Assignment (subtract 5 from x → x = x - 5), and the analyzer's Assignment arm checks the target for constness. add is different: add 10 to x is ambiguous at parse time (x may be a number → arithmetic, or a list → append), so parse_add_operation always emits Statement::AddToListStatement and leaves the choice to the interpreter. That arm only checked that the target name was defined, never that it was writable.

The reason it looked like a combination-only bug: add 10 to MAX_SIZE alone does still fail — analysis passes, the program runs, and Environment::assign rejects the write with the same message. Put it next to other mutations and analysis fails first, so the run never happens and the report never appears.

remove ... from and clear share the statement shape and had the same hole.

Fix

The analyzer now tracks constants explicitly in a constant_bindings set of SymbolBindingKeys, populated when a store new constant declaration is defined, consulted by a new report_constant_mutation helper from all three bare-name mutation statements. Keying by binding rather than by name keeps an inner-scope shadow from being mistaken for the constant.

Notably, SymbolKind::Variable { mutable: false } is not a usable test for "is a constant" — action parameters, container-method parameters (a separate code path), loop variables, try/when error bindings, predefined globals, and every Analyzer::with_parent_variables REPL binding are registered immutable without being constants. The first attempt used that predicate and broke TestPrograms/test_create_list_expression.wfl, which legitimately does add "processed" to list_param.

This also closes a runtime hole: a constant number was already protected by Environment::assign, but add/remove/clear on a constant list mutated the Rc<RefCell<Vec<Value>>> in place without reassigning the binding, so the constant check was bypassed entirely and it silently succeeded.

Result

$ wfl repro.wfl
error[ANALYZE-SEMANTIC]: Cannot modify constant 'MAX_SIZE' - constants are immutable once defined
... (5 reports, exit 3)

tests/diagnostics_fixtures_test.rs::constant_mutation_is_rejected_for_every_mutation_form can be tightened from >= 4 to >= 5 — note that fixture and test are not on main yet, so this branch does not touch them.

Tests

tests/constant_mutation_analyzer_test.rs, committed test-only first as Red evidence:

Test	Red	Green
add_to_constant_is_rejected_on_its_own	0 reports, expected 1	pass
every_mutation_form_of_a_constant_is_reported	4, expected 5	pass
list_mutation_statements_reject_constant_targets	0, expected 3	pass
mutable_targets_are_still_accepted	pass	pass
list_parameters_and_loop_variables_are_not_constants	pass	pass
container_members_are_not_constants	pass	pass

The last three are negative assertions that the check does not over-report; the two parameter tests were added after the over-reporting bug described above.

Also run: cargo test --all --no-fail-fast (150 suites, 0 failures), cargo clippy --all-targets --all-features -- -D warnings, cargo fmt --all -- --check, all 111 non-skipped TestPrograms/ programs against the release binary, and scripts/validate_docs_examples.py (21/21).

Docs

Docs/03-language-basics/variables-and-types.md said "Currently, all variables can be changed. True constants (immutable values) are planned for future versions", and Docs/06-best-practices/naming-conventions.md said "True immutability is limited today" — both false since store new constant shipped. Both now document the real syntax and every rejected mutation form, with two validated examples registered in the docs-examples manifest. Dev Diary: Dev diary/2026-07-31-issue-671-constant-mutation-reports.md.

Known limitation, deliberately out of scope: push with <const list> and <value> takes an arbitrary expression for its target rather than a bare name, so it does not share the statement shape fixed here and still mutates a constant list without complaint. Closing that needs the analyzer to resolve write-targets through expressions.

No pull request opened — say the word if you want one.

---

Generated by Claude Code