-Wno-shadow-uncaptured-local suppresses a different set on each clang, so the WASM leg is the only one enforcing structured-binding shadowing

[Yaraslaut]

What happens

cmake/compiler_options.cmake's Clang branch passes -Wno-shadow-uncaptured-local to every Clang-family target. Which diagnostics that flag actually suppresses turns out to differ between the clang releases morph builds with, and one diagnostic — declaration shadows a structured binding — falls inside the suppression on Linux clang 22.1.8 and outside it on the emsdk clang the WASM legs use.

The consequence is not cosmetic: that diagnostic class is enforced on exactly one CI leg, and no local build on the toolchain morph otherwise develops with can reproduce it. A developer can run a full -Weverything -Werror clang build, see it green, and still be rejected by the WASM leg for a warning that build was structurally unable to emit.

Verification status

Reproduced, on 7ab4c7a9 plus PR #661's first two commits (dbe10202), by both toolchains.

The WASM leg's own failure, from the log of run 35573507189 (job 106250062389):

/home/runner/work/morph/morph/include/morph/core/bridge.hpp:2112:38: error: declaration shadows a structured binding [-Werror,-Wshadow]
/home/runner/work/morph/morph/include/morph/core/bridge.hpp:2118:50: error: declaration shadows a structured binding [-Werror,-Wshadow]
/home/runner/work/morph/morph/include/morph/core/bridge.hpp:2297:50: error: declaration shadows a structured binding [-Werror,-Wshadow]
/home/runner/work/morph/morph/include/morph/core/bridge.hpp:2303:50: error: declaration shadows a structured binding [-Werror,-Wshadow]

The compile line in that same log contains -Wno-shadow-uncaptured-local, so the suppression was in effect and did not cover the diagnostic. Toolchain: emsdk 3.1.56, Qt 6.8.3 wasm_singlethread.

The same source, same project flags, on local clang 22.1.8:

$ clang++ -std=c++23 -fsyntax-only -Weverything sb.cpp
sb.cpp:12:15: warning: declaration shadows a structured binding [-Wshadow-uncaptured-local]

Note the group: -Wshadow-uncaptured-local, not -Wshadow. Because morph suppresses that group, a clang-22 build of the identical code is silent. Confirmed against the real tree, not just the reduction — a -Weverything -Werror clang 22.1.8 build of morph_tests at dbe10202 compiled all 58 affected TUs with zero diagnostics while the WASM leg was failing on four.

Minimal reproduction:

#include <functional>
#include <utility>
std::pair<std::function<void(int)>, std::function<void(int)>> make();
void sink(std::function<void()>);
void f() {
    auto [onRegistered, onFailed] = make();
    int newId = 1;
    auto outer = [onRegistered, newId]() mutable {
        sink([onRegistered = std::move(onRegistered), newId] { onRegistered(newId); });
    };
    outer();
}

Dropping just -Wno-shadow-uncaptured-local from the project's own flag list for a TU that includes bridge.hpp makes clang 22 report the same four sites the WASM leg reported, which is how PR #661 verified its fix locally:

before: shadows a local variable: 18   shadows a structured binding: 4
after:  shadows a local variable: 18

Not verified: which clang release the reclassification landed in, and whether any other diagnostic is split across the two groups the same way. Only shadows a structured binding and shadows a local variable were observed, and only the first diverges. No emsdk toolchain was available locally, so every emsdk-side statement here is read off the CI log rather than run.

Why this is worth fixing rather than living with

The suppression's intent — spelled out in compiler_options.cmake as "lambda param shadowing an uncaptured local" — is about local variables. Shadowing a structured binding from an init-capture that moves from it is a different and arguably more interesting construct, and nothing recorded suggests anyone decided to suppress it. It is suppressed on most legs by accident of how one clang release groups diagnostics.

The reverse case is the worry: a diagnostic that today only the emsdk clang reports could tomorrow be reclassified the other way, and a class of warning would go from "enforced on one leg" to "enforced nowhere" with no CI change and nothing to notice it.

Possible remedies (not evaluated)

• Narrow the suppression to what it says it is, e.g. re-enable -Wshadow explicitly after -Wno-shadow-uncaptured-local, and fix or individually suppress the 18 pre-existing local-variable shadows in backend.hpp, completion.hpp, registry.hpp, callback_scope.hpp, bridge.hpp.
• Keep the suppression but add a Linux-clang leg that drops it, so the WASM leg stops being the sole enforcer.
• Decide the construct is fine and suppress it by name on both, which at least records the decision.

What would change the verdict

• Close as invalid if the divergence is an artifact of the reduction rather than the group assignment — i.e. if an emsdk build with -Wno-shadow-uncaptured-local does suppress shadows a structured binding and the four CI errors had some other cause.
• Close as fixed once a diagnostic in this class fails a leg that a developer can run locally on the toolchain morph is built with, demonstrated by mutating the code and watching that leg go red.

Found while fixing the four -Wshadow errors in PR #661; filed rather than folded in, per AGENTS.md.

[Yaraslaut]

Triage: valid — I confirmed this one against my own mistake

I am the reason this issue exists. Diagnosing #661 I told the lane "GCC does not diagnose this, which is why the GCC-only local build was clean" — and that was wrong. Verified on 7ab4c7a9:

$ grep -n shadow cmake/compiler_options.cmake
161:        -Wno-shadow-uncaptured-local    # lambda param shadowing an uncaptured local
233:        -Wshadow

The project enables -Wshadow and suppresses -Wshadow-uncaptured-local tree-wide. clang 22 files an init-capture shadowing a structured binding under the suppressed flag; emsdk 3.1.56's older clang files the identical construct under plain -Wshadow. So a full local clang -Weverything -Werror build is silent too, and the WASM leg is the only place in CI where this class is enforced.

triage: valid, bug, area: ci.

What makes it worth fixing rather than noting: the coverage is not a decision anybody made. It is a by-product of two toolchains disagreeing about which flag owns a diagnostic, and it will move again — silently — the next time either clang version changes. A gate whose reach depends on an undocumented version difference is one upgrade away from covering nothing, and nobody would notice, because the only signal it ever produces is a red WASM leg on a PR that has nothing to do with WASM.

It has already cost a cycle: #661 was diagnosed, fixed and pushed on the strength of a clang build that could not see the problem.

For whoever takes it

• Establish the fact first. Which clang versions file this construct under which flag is the whole ticket; everything else follows. The two data points here are clang 22.1.8 (suppressed flag) and emsdk 3.1.56's clang (plain -Wshadow) — worth pinning down where the change happened.
• Then decide what the suppression is actually for. -Wno-shadow-uncaptured-local is commented "lambda param shadowing an uncaptured local", which is a narrower thing than "any init-capture shadowing anything". If the suppression is broader than its stated reason — and the evidence here says it is — that is the same defect class as examples/common/testkit/.clang-tidy also governs the testkit *library* sources, contradicting its own prose #652 and HeaderFilterRegex excludes every examples/** header from clang-tidy: 49 findings from five of 737 TUs #664, one flag down.
• Do not simply delete the suppression and see what breaks; measure the finding count first, the way 97 unreported clang-tidy findings in the eleven bank-GUI sources morph#651 brings into reach #656 and 84 clang-tidy findings become reachable in the two AUTOMOC self-including TUs once #624's fix lands #646 were handled, or this becomes an unbounded cleanup wearing a one-line diff.

What would change the verdict

Close as invalid if the two clangs turn out to agree and the real cause is something else in the WASM leg's flag set — in which case the finding is that the WASM leg differs for a reason nobody has identified, which is still worth a ticket, just a different one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Fact established, comment corrected, issue left open

Taking the ticket's own first step — "establish the fact first. Which clang
versions file this construct under which flag is the whole ticket."

The flag's real reach, clang 22.1.8

clang++ -std=c++23 -fsyntax-only -Weverything, one construct per function:

probe.cpp:9:22:  declaration shadows a local variable      [-Wshadow-uncaptured-local]   [](int value){...}
probe.cpp:16:24: declaration shadows a local variable      [-Wshadow-uncaptured-local]   [] { int value = 2; ... }
probe.cpp:23:16: declaration shadows a local variable      [-Wshadow-uncaptured-local]   [value = 7] { ... }
probe.cpp:30:16: declaration shadows a structured binding  [-Wshadow-uncaptured-local]   [first = first + 1] { ... }
probe.cpp:37:11: declaration shadows a local variable      [-Wshadow]                    { int value = 2; }   (no lambda)
probe.cpp:44:48: declaration shadows a local variable      [-Wshadow]                    [value] { int value = inner; ... }

This refines the ticket's framing. The split is not "structured binding
versus local variable". Rows 3 and 4 differ only in what is shadowed and land in
the same group; rows 5 and 6 are both local variables and land in -Wshadow.
The flag routes on whether the shadowing declaration sits inside a lambda with
no capture-default that did not capture the shadowed entity. So
-Wshadow-uncaptured-local means "any declaration inside an uncapturing lambda
that shadows an uncaptured enclosing local or structured binding" — four
constructs, of which the old comment named one, and including the
[x = std::move(x)] idiom this codebase uses throughout.

The ticket's suggested remedy — "re-enable -Wshadow explicitly after
-Wno-shadow-uncaptured-local" — does not work: -Wshadow is already on (via
-Weverything) and the two groups are disjoint, as rows 5 and 6 show. clang has
no group finer than -Wshadow-uncaptured-local, so narrowing to the named
construct is not expressible. The only options are all-or-nothing plus
per-site suppressions, or correcting the record.

Sizing all-or-nothing

Suppression removed, -Werror replaced by -ferror-limit=0 so the build
completes, clang 22.1.8, clang-debug with every optional feature configured
(NET, QT, FORMS_QML, OFFLINE_SQLITE, LOAD_TESTS, HMAC_EXAMPLES,
LADDER, BANK_EXAMPLE):

total emissions: 4856
--- by message ---
   4856 declaration shadows a local variable [-Wshadow-uncaptured-local]
--- distinct sites ---
41

41 sites, 16 first-party files, 35 of them in headers (hence 4856 emissions from
41 sites). Eight each in core/backend.hpp and core/remote.hpp, four each in
core/bridge.hpp and core/completion.hpp. Filed with the full breakdown as
#669.

Note the second line: zero shadows a structured binding. #661 fixed the
only four in the tree, so the diagnostic class the WASM leg exclusively enforces
currently has no instances anywhere. The leg is a trap for the next one written,
not a live gate — which makes this less urgent than "one leg is load-bearing"
suggests, and no less real.

What I changed, and what I did not

Landing on the laneSTRAND-batch-660-662 branch: the comment on
cmake/compiler_options.cmake:161 now records the six-row table, the 41-site
measurement, the fact that the group cannot be narrowed, and the emsdk
divergence cited to the CI log it came from. A suppression whose stated reason
is narrower than its effect is a defect on its own, and that part is fixed.

Nothing about enforcement changed, so this issue stays open. Its own closing
condition is "a diagnostic in this class fails a leg that a developer can run
locally on the toolchain morph is built with, demonstrated by mutating the code
and watching that leg go red", and that is still not true. It is blocked on
#669.

Verification status

• Reproduced on this workstation, x86-64 Linux, clang 22.1.8, on 7a343e6f
  plus the branch above: the six-row table and the 4856/41/16 figures are real
  output.
• Not verified: anything emsdk-side. No emsdk toolchain is available here,
  so the claim that its older clang files the structured-binding case under
  plain -Wshadow remains exactly what the ticket had — read off the log of run
  35573507189 — and is labelled as such in the code comment.
• Not verified: which clang release reclassified it. Only clang 22.1.8 was
  available locally; this is still open, and it is the one part of "establish
  the fact" I could not finish.
• Not verified: whether any other diagnostic is split across the two
  groups the same way. The probe covers six constructs, not the space.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Runner: reopened — this was closed by the #671 merge, and it should not have been

PR #671 was deliberate about this. Its commit says refs #662, not fixes; its squash body states "This does not close #662."; and its description says "One closes, one does not" and "#662 is not closed. Its own condition is …". The lane got this right, and I verified the refs-not-fixes wording before the merge precisely so the issue would survive it.

It closed anyway, at the moment of the merge:

$ gh api .../issues/662/timeline
referenced by Yaraslaut at 2026-09-21T14:28:17Z commit=be0c4a6f
closed     by Yaraslaut at 2026-09-21T16:13:03Z commit=735cc2e9

$ git log -1 --format=%B origin/master | grep -i '662'
… (fixes #660, refs #662) (#671)
* cmake: say what -Wno-shadow-uncaptured-local actually suppresses (refs #662)
**This does not close #662.** …

$ gh pr view 671 --json closingIssuesReferences
(empty)

So there is no closing keyword and no linked closing issue — and GitHub closed it regardless. I cannot account for the mechanism from the evidence available, and I am not going to invent one; what I can say is that the wording that was supposed to prevent it was correct and did not.

Reopened. Nothing about the issue's substance has changed: #671 fixed the comment defect only. The enforcement gap is untouched, and this issue's own closing condition — "a diagnostic in this class fails a leg a developer can run locally, demonstrated by mutating the code" — remains unmet.

Where it actually stands, since the ground moved today

• The cleanup is sized: Sizing the -Wshadow-uncaptured-local cleanup morph#662 needs: 41 distinct sites in 16 first-party files, 4856 diagnostics #669 measured 4856 diagnostics over 41 distinct sites in 16 first-party files.
• Narrowing is not expressible: -Wshadow-uncaptured-local owns four constructs, of which this issue's comment named one, and clang has no finer group. So the remedy this issue was originally framed around cannot be built.
• There is currently nothing to enforce: core: give Bridge an executor for late registration replies, and re-measure what a local dispatch allocates (fixes #588, refs #572) #661 fixed the only four shadows a structured binding sites, so the WASM leg — the sole leg that files this construct under plain -Wshadow — catches nothing today. This is a trap for the next one written, not a live gate.

Whoever picks this up should decide between a targeted lint outside clang's warning groups and accepting the suppression with its now-corrected comment. It is not a 41-site cleanup.

Worth watching for: if a second issue closes on merge despite refs-only wording, that is a pattern rather than an anomaly and deserves its own ticket. One occurrence is not enough to file on.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Consolidation: morph#669 folded in here and closed as superseded

morph#669 was filed as the sizing for this issue and split off only so that
this issue's diagnosis was not blocked behind a measurement. That purpose is
served: nothing here is blocked on diagnosis any more, and the two now resolve
together — morph#669 says so itself in its own closing condition:

Close as invalid if the decision is that the suppression stays
permanently. In that case the comment must carry the argument, and
morph#662 should be closed the same way rather than left implying a
cleanup is coming.

Two issues that can only be closed by the same decision are one issue. Its
evidence is reproduced verbatim below so nothing is lost when it closes.

---

The sizing, reproduced from morph#669

cmake/compiler_options.cmake's -Wno-shadow-uncaptured-local removed,
-Werror replaced with -ferror-limit=0 so the build completes instead of
stopping at the first TU, everything else the project's own flag set. clang
22.1.8 on x86-64 Linux, clang-debug preset with -DMORPH_BUILD_NET=ON -DMORPH_BUILD_QT=ON -DMORPH_BUILD_FORMS_QML=ON -DMORPH_BUILD_OFFLINE_SQLITE=ON -DMORPH_BUILD_LOAD_TESTS=ON -DMORPH_BUILD_HMAC_EXAMPLES=ON -DMORPH_BUILD_LADDER=ON -DMORPH_BUILD_BANK_EXAMPLE=ON.

total emissions: 4856
--- by message ---
   4856 declaration shadows a local variable [-Wshadow-uncaptured-local]
--- distinct sites ---
41

41 distinct file:line:col sites in 16 first-party files. 35 of the 41 are in
headers, which is why 41 sites produce 4856 diagnostics — each is re-reported
by every TU that includes the header. Nothing in a dependency is affected; they
arrive via -isystem.

8  include/morph/core/backend.hpp        2  examples/ledger/gui_lib/report_presenter.cpp
8  include/morph/core/remote.hpp         2  examples/pastebin/gui_lib/paste_forms_controller.hpp
4  include/morph/core/bridge.hpp         2  examples/polls/gui_lib/poll_forms_controller.hpp
4  include/morph/core/completion.hpp     1  examples/bookmarks/gui_lib/bookmark_forms_controller.hpp
1  include/morph/core/registry.hpp       1  examples/pastebin/tests/test_paste_model.cpp
1  include/morph/core/callback_scope.hpp 2  tests/test_conflict_resolution.cpp
1  include/morph/offline/sync_worker.hpp 1  tests/test_backend_extra.cpp
1  include/morph/qt/qt_executor.hpp

What the sites are — and why this is the crux

Overwhelmingly the move-into-continuation idiom, include/morph/core/bridge.hpp:1232:

include/morph/core/bridge.hpp:1232:50: error: declaration shadows a local variable [-Werror,-Wshadow-uncaptured-local]
 1232 |                 detail::deliverLate(bridgeExec, [onFailed = std::move(onFailed), failure] {
      |                                                  ^
include/morph/core/bridge.hpp:1193:14: note: previous declaration is here
 1193 |         auto onFailed = [typeId = binding->typeId](const std::string& message) {
      |              ^

This is deliberate, idiomatic and correct. The init-capture moves the
enclosing object and reuses its name; the outer one is dead afterwards. So the
cleanup is renames, not bug fixes — 41 renames of moved-from callables and
completion handlers across bridge.hpp, remote.hpp, backend.hpp and
completion.hpp, which is 41 chances to rename the wrong one in the framework's
most lifetime-sensitive code, for zero behaviour change.

Verification status, carried over unweakened

• Reproduced. The counts are from a build on 7a343e6f plus the morph#660
  branch (which touches none of these sites), not from reading. Both excerpts are
  real compiler output.
• Not verified: that the count holds on any other toolchain. It is
  clang-22-specific by construction, and this issue shows the grouping moves
  between clang releases — an older clang classifies some under plain -Wshadow.
• Not verified: the count on the WASM configuration. No emsdk was available.
• Not measured: how long the renames take, or whether any site resists a
  clean rename.

---

What this issue now is: one decision, with its cost attached

The flag cannot be narrowed — clang has no finer group — so enforcing anything in
this class on a leg a developer can run means dropping the suppression, which
means the tree must first be clean under it. Hence exactly two outcomes:

(a) Do the cleanup. 41 renames, zero behaviour change, in the most
lifetime-sensitive headers in the tree. Then delete the suppression from
cmake/compiler_options.cmake. Acceptance is not "no warnings" — it is
adding a shadow and watching a locally-runnable clang leg go red.

(b) Keep the suppression, permanently and on the record. Cheap, defensible,
and has never been written down anywhere — which is the actual defect today.
The argument goes in cmake/compiler_options.cmake beside the flag, and this
issue closes citing it.

Both are defensible. What is not defensible is the current state: a suppression
with no recorded decision and an issue implying a cleanup that nobody has
committed to.

This is a decision for the repository owner, not for a lane — which is why it
has sat undispatched across several sweeps. One sentence unblocks it.

triage: valid unchanged. area: ci unchanged.

[Yaraslaut]

Closed — out of scope under the CI reduction

This issue proposes adding or tightening CI enforcement. morph#755 moved in the opposite direction deliberately: the check surface had reached 57 checks per PR across 51 jobs and 31 checker scripts, while more than half the open backlog was CI maintaining itself. The meta-gates — the checks policing other checks — were removed.

The finding itself is not disputed and the analysis stands; what has changed is the appetite for enforcing it in CI. Closed as not planned, not as invalid.

No compile, test, sanitizer, coverage or platform coverage was removed — every build, sanitizer, Valgrind, coverage and platform leg still runs. The trade is that pins, citations and conventions of this kind are now conventions rather than gates.

Re-open if the cost/benefit changes — the evidence recorded here would not need re-gathering.