docs: ADR 005 — design the --strict-types (Phase 2) pass#27
Conversation
Splits what ADR 002 originally described as one "Phase 2" into two sub-phases: 2a (static type resolution via go/types, closing issues #15 interface satisfaction and #16 transitive factory wrapping — both pure "what is this expression's real type" questions) and 2b (interprocedural data-flow, closing issue #26 cross-function method values — a meaningfully larger, riskier undertaking needing real call-graph analysis, not just type info). This ADR scopes only 2a; 2b gets its own future ADR once 2a has shipped and proven out the package-loading and fallback machinery in practice. Covers: package loading via golang.org/x/tools/go/packages, fail-soft per-package fallback to Phase 1 results when a package doesn't type-check (never breaking the "audit works with no build" guarantee), the identity resolution model (still never inferred from a name, now proven through the type checker instead of syntax), and the CLI/API surface (--strict-types as a flag, not a config-file field, since it's a Go-only concept with no flaglint-js equivalent; scanner.ScanStrict as a new function wrapping the unchanged scanner.Scan). Signed-off-by: Krishan Kant Sharma <krishansharma0327@gmail.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a new architecture decision record (ADR 005) documenting an opt-in ChangesADR Documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Design ADR for the opt-in
--strict-typespass ADR 002 originally sketched. Splits it into two sub-phases:go/types, closing scanner: interface satisfaction is not resolved — a client known only through an interface type #15 (interface satisfaction) and scanner: factory-function resolution is one hop only — a factory returning a wrapper type isn't traced #16 (transitive factory wrapping) — both pure "what is this expression's real type" questions.go/typesalone gives a parameter's declared type, not proof a specific call site passed a specific real client's method into it; that needs real call-graph analysis (go/ssa/go/callgraph), a meaningfully larger and riskier undertaking than 2a. Bundling both would risk delaying the contained value of 2a or under-baking 2b.Covers package loading (
golang.org/x/tools/go/packages), fail-soft per-package fallback to Phase 1 results when a package doesn't type-check (the "no build required" guarantee stays intact for the rest of the tool), the identity resolution model, and the CLI/API surface (--strict-typesas a flag — not a config-file field, since it's Go-only with no flaglint-js equivalent).Test plan
Summary by CodeRabbit
--strict-typesmode for identity resolution.