cl: tolerate invalid receivers during syntax preload - #2226
Conversation
There was a problem hiding this comment.
Review summary
Reviewed the full 8-commit diff (cl/import.go core change + test/goroot recovery-pairing harness and xfail removals). The core refactor is correct and well-guarded:
recvTypeNameInfo/astFuncNameOKfail safe on every non-Ident/non-simple-index receiver shape (includingnil), correctly normalize parenthesized, pointer, and generic (G[P],((*G[P]))) forms viaast.Unparen, andParsePkgSyntaxnowcontinues on an unconvertible receiver instead of panicking.- The retained
panic("unreachable")inrecvTypeName/astFuncNameis only reachable from the post-typecheckinitFilespath, so it is a genuine invariant guard rather than a latent crash on malformed source. - The test coverage (fail-open: missing/mismatched/wrong-line/wrong-file/line-directive primaries;
TestParsePkgSyntaxSkipsInvalidReceiver) is thorough, and thediagnosticPathResolver.resolvetightening is a good hardening.
No bugs, regressions, security, or performance issues found. Doc comments match final-state code. One minor maintainability nit posted inline; the remaining observations below are optional.
Optional (non-blocking)
test/goroot/runner_test.go—parserRecoverySecondaries/parserRecoverySourceSecondaries/parserRecoverySecondaryGroupsform a hand-maintained catalog of exact GOROOT source shapes and exactgo/parserdiagnostic spellings. This is intentional and well-commented, but the literals are version-sensitive (see theinvalid use of ...Go-version difference already captured) and will silently rot on a Go bump. Consider consolidating the three functions into a single data table (primary, optional exact-source, secondary-groups) plus a note on how to regenerate/verify the golden spellings when bumping Go.cl/import.go:385,426— a one-line comment on each panic wrapper noting that the invalid-receiver path is handled byastFuncNameOK/recvTypeNameInfoand this variant asserts a checked (post-typecheck) invariant would prevent a future reader from treating the panic as dead code or a latent crash.test/goroot/runner_test.gohasLineDirective— the//linebranch requires start-of-line-only preceding whitespace while the/*linebranch intentionally does not; this is correct per Go's spec but looks asymmetric. A one-line comment would prevent a future "fix" from breaking it.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
9d4d009 to
51d67b2
Compare
|
Rebased onto the updated #2222 head after #2218 merged, then addressed the review and Codecov gaps in The update documents the two post-typecheck invariant wrappers and adds direct counterexamples for an indexed non-identifier receiver base, an invalid array receiver, an index-list receiver, nil declarations and names, empty and nil receiver fields, invalid receiver types, and both invariant panic paths. Validation after rebase:
The new CI and coverage run is in progress. |
Depends on #2222.
Summary
fixedbugs/issue20789.goand remove that xfailThe regression starts with the valid-but-invalid-receiver declaration
func ([]int) m() {}. It also covers the review counterexamples((*T)),(*(T)), generic value receivers, and parenthesized generic pointer receivers, so the checked path does not reject legal receiver syntax.Validation
go test ./cl -run "^(TestParsePkgSyntaxSkipsInvalidReceiver|TestAstAndTypesFuncNameCoverage|TestParsePkgSyntax.*)$" -count=1go test ./internal/packages ./cmd/internal/compile ./test/goroot -count=1fixedbugs/issue20789.gowith an empty xfail set on Go 1.24.11, 1.25.0, 1.26.0, and 1.26.5git diff --checkNo broad package parse-error gate is added; unrelated declarations and packages keep their existing preload behavior.