-
Notifications
You must be signed in to change notification settings - Fork 18k
go/types, types2: missing diagnosis for structs that contain themselves through type parameters #65711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If I understand correctly, this should be rejected by the typechecker and not reach types2, right? |
@golang/compiler |
I agree, I think this is a typechecker issue: This analogous non-generic code is correctly rejected:
Retitling as a go/types + types2 issue. |
Definitely a bug. The optimization in validtype.go (exit early for *Named types) is incorrect (caches break things). |
Change https://go.dev/cl/567975 mentions this issue: |
Change https://go.dev/cl/567976 mentions this issue: |
Change https://go.dev/cl/567916 mentions this issue: |
Debugging support. For #65711. Change-Id: I2b8b03d2c6e02d32a4f9272313e852f17da35b3e Reviewed-on: https://go-review.googlesource.com/c/go/+/567975 Reviewed-by: Robert Findley <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Provide an explicit start position to Checker.cycleError for better control over the reported error. For #65711. Change-Id: Ie3016523442d75f348a033c1b944db493943f433 Reviewed-on: https://go-review.googlesource.com/c/go/+/567916 Auto-Submit: Robert Griesemer <[email protected]> Reviewed-by: Robert Findley <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Griesemer <[email protected]>
What did you do?
While working on formal methods (in the style of Featherweight Go) and a prototype type checker and interpreter for #65555, I stumbled across an example program that crashes the Go compiler (try it out in the playground):
(note: this program looks silly because it is part of my interpreter's testing suite, explicitly meant to test various edge cases in the type checker)
This program causes a stack overflow in the Go compiler. The expected outcome is that the compiler rejects such a program, due to an indirectly self-referential struct type via type parameters.
This bug also occurs for array type declarations, using the same setup (playground):
The interesting thing is that this bug only seems to trigger in certain permutations of the type declarations (i.e. order of the declarations matters). E.g. if we place
Baz
beforeBar
or beforeFoo
, then the compiler correctly rejects the program (i.e. without crashing).E.g. the following program is correctly rejected by the compiler (playground):
Related issues
#60817 reports deadlocks with recursive generic types.
What did you see happen?
The output of
go build
:What did you expect to see?
The type checker consistently reporting a type error due to a self-referential type, regardless of the type declaration order, without the compiler crashing.
Expected output (modulo line numbers):
Go version
go version go1.22.0 darwin/arm64
Output of
go env
in your module/workspace:The text was updated successfully, but these errors were encountered: