[wildcard] Self-Hosted In-Process Analysis: Native Go Library Driver (x/tools/go/analysis) for Zero-Install IDE Checking and Compiler Unification #268

The idea, in a paragraph

Directly answering Active Solicitation Prompt 5 in MOONSHOT.md ("Rewrite us. If the whole compiler should be a Go program (self-hosted analysis), a WASM engine, or a library rather than a CLI — say why and what it unlocks"):
Kill the monolithic standalone Rust CLI binary (hyb) as the sole entrypoint for Hybrid compilation and borrow checking. Re-architect Hybrid's analysis engine into an in-process library driver conforming to Go's standard golang.org/x/tools/go/analysis.Analyzer interface (implemented either as a self-hosted pure-Go engine or via an embedded zero-overhead WASM runtime like wazero). This transforms Hybrid from an isolated external CLI into an embeddable compiler library that runs in-process inside gopls for zero-install instant IDE diagnostics, integrates natively into go vet and golangci-lint, exposes an interactive client-side web playground on GitHub Pages via WebAssembly, and replaces brittle string-based foreign type stubbing with live, typed Go symbol tables.

Which assumption it breaks

This breaks the foundational architectural premise established in PLAN.md and Spike 1:

1. The External CLI Assumption: The assumption that borrow-checking and code generation must be performed by a standalone binary executed via subprocesses (hyb check <file.hy>, hyb build <file.hy>).
2. The Rust Toolchain Gate: The assumption that anyone checking, building, or contributing to Hybrid must install a multi-gigabyte Rust toolchain (cargo, rustc, libclang, LLVM).
3. The Opaque Foreign Type Boundary (§8.4 C8 / foreign.rs): The assumption that the checker cannot see real Go package declarations, necessitating hardcoded stubs in foreign.rs and fail-closed rejections (HYB-E3005) for unmodeled types. An in-process analysis.Analyzer receives Go's fully-typed *types.Package and *types.Info directly from the Go compiler/gopls cache.

Why this is a breakthrough, not an increment

A normal feature bounty focuses on adding diagnostics, fixing edge cases in loans.rs, or optimizing parser performance by 5%. This proposal attacks the distribution, adoption, and integration bottleneck of the entire project:

• Zero-Install IDE Diagnostics (<1ms vs 35ms): Currently, editor extensions must shell out to hyb as an external process on every keystroke, paying 15-40ms in OS process creation, stdio serialization, and AST reconstruction. An in-process analysis.Analyzer runs directly within gopls in under 1ms, eliminating editor lag.
• Instant Go Ecosystem Adoption: 99% of Go teams cannot adopt a tool that requires installing Rust on developer laptops and CI builders. Delivering Hybrid as an x/tools/go/analysis plugin allows teams to add Hybrid to .golangci.yml or go vet -vettool with a single Go dependency line (go get github.com/limitlessprojects/go-hybrid).
• Zero-Infrastructure Browser Playground: Compiling the analysis engine to WASM enables a fully interactive browser IDE running entirely client-side on GitHub Pages, dropping the barrier to entry for prospective users to zero.
• Differentiation from [wildcard] Erase the .hy / .go Split: Whole-Package Tier-0 Checking via Native Go AST and Export-Data Analysis #186: Proposal [wildcard] Erase the .hy / .go Split: Whole-Package Tier-0 Checking via Native Go AST and Export-Data Analysis #186 proposes erasing the .hy file syntax to write .go files with inline directives, but leaves the compiler engine unspecified. This proposal answers Prompt 5 directly by transforming the engine itself into an embeddable library and WASM runtime, regardless of whether the input is .hy or annotated .go.

How we would know it works (or doesn't)

Milestone 1 () — Corpus & Pipeline Parity via In-Process Analyzer:

1. Construct an experimental driver embedding the borrow checker (either via a self-hosted Go package or an embedded wazero WASM instance running hy-check.wasm).
2. Implement the standard analysis.Analyzer contract (Run(pass *analysis.Pass) (interface{}, error)).
3. Run the driver against all 46 test cases in tests/checker-corpus/.
4. Falsification Gate for M1:
   • The in-process analyzer must achieve 100% verdict agreement against all 46 corpus programs (all 31 REJECT fixtures reject with pre-registered diagnostics; all 15 ACCEPT / ACCEPT-MANAGED pass).
   • If in-process execution encounters state leakage across analysis passes, unrecoverable stack overflows during deep Polonius borrow walks, or memory bloat exceeding Go's GC thresholds, M1 is recorded as a published architectural failure documenting why standalone process isolation is mandatory.

Milestone 2 () — Sub-Millisecond IDE Latency & CI Footprint Benchmark:

1. Benchmark keystroke-to-diagnostic latency: Measure 100 sequential file modifications across a 25-file workspace comparing external hyb CLI invocations against the in-process analysis.Analyzer inside gopls.
2. Benchmark CI onboarding footprint: Measure Docker build time and image size for a standard Go service CI pipeline with Hybrid verification (Alpine Go image + Go module vs Go + Rust/Cargo build environment).
3. Published Learning Deliverable:
   • Publish a comprehensive analysis to MOONSHOT.md:
     • If successful: Architectural blueprint and migration roadmap for packaging Hybrid as a zero-dependency Go module and WASM bundle.
     • If failed: An evidence-backed analysis detailing the precise performance, memory, or language-impedance walls that justify keeping the compiler in an isolated Rust binary.

Cost honesty (optional but powerful)

• What gets deleted:
  • Standalone subprocess spawning scripts and harness wrappers (corpus_harness.py, differential_loop.py process wrappers).
  • Brittle filesystem heuristics for package sniffing (e.g. searching adjacent .go files to avoid HYB-E9002).
  • Redundant CLI argument handling and exit-code translation logic.
• What gets rewritten:
  • The checker boundary: instead of reading CLI flags and emitting JSON to stdout, the engine consumes an abstract syntax tree and produces structured analysis.Diagnostic objects.
  • Foreign type modeling: foreign.rs can be replaced with direct queries against pass.TypesInfo.Types[expr].
• Migration path:
  • A dual-engine transitional phase: The CLI hyb binary remains available as a lightweight wrapper that simply invokes the Go/WASM analysis library, ensuring zero backwards incompatibility for existing scripts.

Track terms

• I understand no prototype is required and failure-with-knowledge is a valid, paid outcome
• I understand all outcomes (including declines and failures) are published in MOONSHOT.md

Prepared with Gemini CLI / AI assistance; operator reviewed the proposal, architectural evaluation, and milestone criteria.