[clang-campaign] SCALE tail: broad-binding correctness (the 284-error / bare-enum-qualification thesis)

[monkopedia-coder]

Campaign SCALE tail — broad-binding correctness ("massive binding" thesis). The demo runs with a 16-class slice, but the campaign's stated product goal is binding LARGE libraries. Forcing the full transitive Clang surface (~1269 classes via INCLUDE_MISSING) currently yields ~284 generated-C++ compile errors (measured 2026-06-06, recorded in docs/clang-bootstrap.md Backlog as the T1.3-clang/"harden broad binding" P2 tail). It is dominated by 179× "use of undeclared identifier" — the doc notes this is "likely ONE systematic bug (bare enum constants / static members emitted unqualified)." That single fix is the highest-leverage scale unlock.

Do: root-cause + fix the bare-enum/static-member qualification bug first (biggest cluster), then iterate the remaining categories (incomplete-type, deleted-ctor residuals, fn-ptr, etc.) via the rebuild-kexe + real-Clang re-probe loop documented in the doc. Large + iterative. Acceptance: the forced broad surface compiles (error count → low single digits), proving the binding pipeline scales. NOTE: this is the bulk of "make it releaseable as a scale story" — size accordingly.

[monkopedia-coder]

#10 re-investigation (2026-07 fresh, current main @ c20c97d, LLVM 22.1.6): the broad force RUNS — no crash/empty-output/SEGV — but is CPU-bound for tens of minutes in the forcing resolve. Fresh error count NOT obtainable in-env; root cause below.

Re-ran the broad-surface harness on current main in a dedicated worktree (-PenableClang, Xmx12g). Key updated facts that make the old 284/179 "use of undeclared identifier" thesis STALE and re-frame the measurement blocker:

1. krapper_gen no longer self-parses — the force is now a 2-stage krapper_parse → krapper_gen pipeline

Flip B5 (#47) deleted the in-tree libclang-C reducer. The broad force is now: the LLVM krapper_parse binary emits a ModelIo JSON (base_model.json + one KrapperForce_*.json per --instantiate), then krapper_gen --parsedModel <base> --forcingModel <spec>=<path> consumes it. The exact historical single-kexe INCLUDE_MISSING invocation from the old doc no longer exists. I reconstructed the equivalent from the plugin's runKrapperParseSync and drove krapper_gen directly against the clangwalk clang_slice.h models.

2. The broad force does NOT crash and does NOT emit empty output — it RESOLVES, then grinds

Forcing std::vector<clang::Decl*> over clang_slice.h (ASTUnit + DeclCXX + ASTContext + Tooling) with -r INCLUDE_MISSING and no --only scoping:

• Found 3745 classes to resolve (the whole transitive Clang+LLVM world — OpenMP directives, PassBuilder, MachineFunction, the analyzer, VFS, opt tables…). Old doc said 2544→1269; on LLVM 22 it's larger.
• Main resolve completes, then requestInstantiation → resolveForcing reports "Found 3625 classes / Scoped forcing to 3221 element(s)" and enters a multi-pass forcing resolve.
• Process is CPU-bound (~100% one core), bounded memory (peaked ~1.15 GB, no OOM, no SEGV, no abort). After >30 min it was still in the forcing-resolve pass — never reached codegen / the C++ compile. So the "empty output / whole-LLVM-world SEGV" characterization is stale: today it's a performance wall, not a crash.

3. Root cause of the measurement blocker (the real #10 scale defect)

Two compounding costs in the forcing path (IndexedServiceImpl.requestInstantiation → Resolver.resolveForcing):

• (a) The forcing re-parse of std::vector<clang::Decl*> under INCLUDE_MISSING resolves clang::Decl's ENTIRE transitive closure (~3600 classes) regardless of --only. The synthetic KrapperForce_* header #includes the consumer headers, so findClasses { defaultFilter() } collects the whole TU, and INCLUDE_MISSING then recursively resolves every referenced type. This is the dominant, unavoidable cost, and it is the same whether or not you scope the main pass.
• (b) With no --only, alreadyBoundKeys = the ~1900 main-pass-bound classes, so resolveForcing also RE-RESOLVES all of them across its 3 passes → O(bound-classes) on top of (a). Adding the 18-class --only allowlist (clangwalk's list) removes (b) — memory drops from ~1.15 GB to ~0.4 GB — but (a) remains: the scoped run was STILL in the forcing resolve at 10 min+ (~740 CPU-sec, RSS climbing), never reaching codegen either.

Net: the broad force is gated on resolver throughput at ~3600-class scale, not on a crash and not on the codegen correctness bugs the old thesis chased. A working error-count harness needs the forcing resolve to be tractable first — either (i) make resolveForcing's INCLUDE_MISSING expansion of the forced element's closure bounded/lazy (don't fully resolve every transitive class just to materialize the container specialization), and/or (ii) memoize/skip already-resolved classes across the 3 forcing passes. Until one of those lands, the ~3600-class forced surface cannot be compiled+counted in a practical timeout on this box.

Honest status: fresh broad-surface error count NOT produced (the force does not reach codegen in a reasonable wall-clock here). The old 284/179 number should be treated as retired, not as a target — the current blocker is the forcing-resolve performance wall described above, which is where #10's "make broad binding scale" work should now focus.

4. Adjacent finding — the default :featuregen:kplusplusSync exit-134 is EXPECTED stage-0 drift, benign (not a fresh-consumer regression)

A plain ./gradlew :featuregen:kplusplusSync (no -PenableClang) aborts krapper_gen with exit 134 (SIGABRT). Root cause captured directly: it uses the published 0.3.2 krapper_parse (~/.gradle/kplusplus/tools/0.3.2/krapper_parse) because the in-tree :krapper_parse is LLVM-gated and absent without -PenableClang. That 0.3.2 tool predates commit 3721afc "krapper_gen: skip methods whose signature references an inaccessible (protected/private) nested type (#123)", so its model binds AccessProbe::useHiddenEnum(HiddenMode) — whose param is the protected nested enum that is exactly the #123 fixture (strings_feature.h:917). The generated wrapper then emits (AccessProbe::HiddenMode)m → "'HiddenMode' is a protected member of 'AccessProbe'" → CppCompiler.compile's require(exit==0) throws → SIGABRT.

With -PenableClang (the intended default, using the in-tree krapper_parse) the same sync succeeds — 122 Kotlin files, clean. So this is the expected one-release-behind bootstrap drift: main's C++ surface (the #123 test) has legitimately moved ahead of the published 0.3.2 stage-0 tool, and the fix already exists on main (it'll ship in the next stage-0). It is not a crash a fresh consumer of the published plugin would hit on their own surface — they'd use 0.3.2's own featuregen, not main's. Recommendation: the default gate should pin the in-tree/cpp path (as gradle.properties already does with kpp.frontend.featuregen=cpp, which requires -PenableClang); no code fix needed.

Investigated in worktree off main c20c97d; no code changes made (the finding is a root-caused blocker + a benign-drift verdict, not a patch).