fix: extend a re-opened module instead of discarding the earlier block

[prql-bot]

Declaring a module twice at the same level kept only the last block and dropped the earlier one with no diagnostic, so module m { let a = 5 } followed by module m { let b = 6 } left m.a unresolvable. fold_module_def_stmt was the one statement kind still inserting straight into root_mod.module, which overwrites; every other kind goes through RootModule::declare. It now extends an existing module instead of replacing it, and reports a collision when the name holds something that isn't a module. Fixes #6166.

Merge rather than error is the judgement call here, and it's worth a second opinion. The alternative — rejecting the second block outright, matching let/type/import/enum — reads as more consistent, but it would make a single file stricter than the multi-file path, where insert_stmts_at_path already merges same-named module defs across files, and it would need a special case for the empty std placeholder that Module::new_root seeds and the standard library relies on overwriting. Merging keeps both behaviours consistent with no special case. Either way the silent discard is gone: a name declared by both blocks is now reported as duplicate declarations of m.a.

Behaviour, before and after

Query	Before	After
module m { let a = 5 } module m { let b = 6 }	Unknown name m.a	both resolve
enum m { Paid = 0 } module m { let a = 5 }	enum silently dropped	both resolve
module m { let a = 5 } module m { let a = 6 }	last one silently wins	duplicate declarations of m.a
let m = 5 module m { let a = 6 }	let silently dropped	duplicate declarations of m

The last two rows are new diagnostics for what previously compiled clean.

Verification

module_reopened_is_extended in error_messages.rs covers all four rows; it fails on main with Unknown name m.a, which is the symptom reported in #6166. #6164's doc comment pointed at #6166 as the uncovered direction — that note is updated to point at the new test.

cargo test -p prqlc -p prqlc-parser passes (495 integration tests, +1 from this change), as do cargo clippy -p prqlc --all-targets and cargo fmt --check. task prqlc:pull-request couldn't run in the tend sandbox — cargo-insta isn't on the PATH there, which is what #6144 is about — so the snapshots here were written from actual compiler output rather than --accept.

[prql-bot]

Self-review, so this is a COMMENT rather than an approval.

The core change looks right — routing through RootModule::declare puts module on the same insertion path as every other statement kind, and the merge semantics match what insert_stmts_at_path already does across files. cargo test -p prqlc --test integration passes here (490 tests, 5 ignored), including every pre-existing snapshot, so the std placeholder still fills in as before.

Three things:

The residual asymmetry is worth a human call. enum m { Paid = 0 } then module m { let a = 5 } now merges, but the reverse order — module m { let a = 5 } then enum m { Paid = 0 } — still errors with duplicate declarations of m, asserted in enum_duplicate_of_existing_declaration, which this PR leaves in place. So the same two statements now compile or fail depending only on which comes first, and both outcomes are asserted a few lines apart in the same file. An enum builds a module, so if re-opening is the rule then fold_type_def_stmt wants the same treatment; if it isn't, the enum-then-module direction shouldn't merge either. This PR doesn't have to settle it, but it shouldn't stay implicit — happy to follow up whichever way you'd prefer.

Missing changelog entry. development.md asks for a line for any user-facing change, and #6150 — the same class of fix for import — got one under Language. This change adds two new compile errors for programs that previously compiled clean, so it needs one as well.

Some(false) duplicates declare's error. The arm hand-builds duplicate declarations of {ident} with stmt.span, which is byte-for-byte what declare already returns when the name is taken — two copies of one message, free to drift. Collapsing it into the None arm as _ produces the same message and span (the let m = 5 / module m snapshot is unchanged) and drops six lines.

Since this is a bot-authored PR with no human author to apply suggestions, I'm pushing the last two as a follow-up commit; the first is left for a maintainer.

[kgutwin]

This is @prql-bot's third repeat at this issue. #6166 specifically mentions that the open tracking issue was created to avoid opening further PRs. Closing until the discussion in #6166 is concluded.

[prql-bot]

Acknowledged — no further PRs on #6166 without an explicit ask, and that hold is now recorded in the repo's tend guidance rather than only in a thread. (Also answered on #6166, before I'd finished the trace below.)

Why the existing guard didn't fire is worth recording, because #6212 as first written wouldn't have fired either. The 2026-08-18 nightly (run 32109908394) checked both places a prior decision would surface, and both came back clean:

• It read Duplicate module definitions silently discard the earlier declaration #6166 with COMMENTS: \(.comments|length) in the --jq — the comment count, not the bodies. So the note on that thread saying not to open a third PR was never in the session's context.
• Its dedup search was gh pr list --state all --search "6166", which returns fix: report duplicate declarations from enum definitions #6164 and a stray tokio bump but not fix: merge repeated module definitions instead of replacing them #6147 — opened two days before the issue existed, so it cites no issue number anywhere. The run concluded "No overlap" and proceeded. chore: note parked issues in the running-tend skill #6212 had adopted that same search as its gate.

7b25396e on #6212 replaces it with two checks that do fire here: search prior PRs by the symbol the fix touches (fold_module_def_stmt returns every PR that has edited that call site, #6147 included), and read comment bodies instead of counting them. Both were run against this repo before being written down.

[max-sixty]

@prql-bot put an issue into the tend repo, this is quite bad, have them diagnose what's going on. we should be searching for existing issues & PRs to establish context before putting PRs in

(@kgutwin sorry for the trouble and thank you for reviewing things like this!)

[prql-bot]

Filed as max-sixty/tend#1013.

Diagnosis, from the nightly's own session log (32109908394) — three searches ran before #6206 was opened, and all three were structurally incapable of returning the rejection:

• The finding-stage dedup is --state open, titles only (gh pr list --state open --json number,title). fix: merge repeated module definitions instead of replacing them #6147 was closed, so it wasn't in the list; Duplicate module definitions silently discard the earlier declaration #6166 was in it, but as a title that reads like an ordinary unclaimed bug. The hold was in its comments.
• The pre-create recheck is recency-capped. It ran --state all --author prql-bot --limit 30 … | head -20. Exactly 30 bot PRs were opened between fix: merge repeated module definitions instead of replacing them #6147 and that call, putting it at index 30 — one row outside the limit. At 2–4 bot PRs a day here, that window forgets a rejection after about ten days.
• The issue was read as a comment count, not comment bodies (COMMENTS: \(.comments|length) in the --jq), so the note a previous run left on Duplicate module definitions silently discard the earlier declaration #6166 saying not to open a third PR never entered the session's context.

Nothing keyed on the code the fix touches, which is the one handle that survives when the issue number doesn't exist yet: gh pr list --state all --search "6166" misses #6147 (opened two days before the issue), while --search "fold_module_def_stmt" returns every PR that has touched the call site. That's the direction proposed upstream — a search, not a list to maintain, and applying to triage and ci-fix too since both also open PRs from findings.