go/test/typeparam/issue51219b.dir/b.go

// Copyright 2022 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package b

import (
	"./a"
)

// InteractionRequest is an incoming request Interaction
type InteractionRequest[T a.InteractionDataConstraint] struct {
	a.Interaction[T]
}
cmd/compile: fix importers to deal with recursion through type constraints The code for issue #51219 reveals bugs in the types1 and types2 importers that can occur for recursive types that are recursive through the type constraint. The crash in the issue is caused by the types1 bug, which leads to the production of a type1 type which is incomplete and improperly has the HasTParam flag set. The bug in the types1 importer is that we were not deferring type instantiations when reading the type parameters, but we need to do that exactly to correctly handle recursion through the type constraint. So, the fix is to move the start of the deferrals (in the 'U' section of doDecl in typecheck/iimport.go) above the code that reads the type params. Once that bug is fixed, the test still crashes due to a related types2 importer issues. The problem is that t.SetConstraint(c) requires c to be fully constructed (have its underlying type set). Since that may not be done yet in the 'U' case in (*importReader).obj() in importer/iimport.go, we need to defer the call to SetConstraint() in that case, until we are done importing all the types. I added a test case with recursion through a type constraint that causes a problem that is fixed by the types1 importer change, though the error is not the same as in the issue. I added more types in the test case (which try to imitate the issue types more closely) the types2 bug, but wasn't able to cause it yet with the smaller test case. Fixes #51219 Change-Id: I85d860c98c09dddc37f76ce87a78a6015ec6fd20 Reviewed-on: https://go-review.googlesource.com/c/go/+/386335 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 2022-02-17 04:11:52 +00:00			`// Copyright 2022 The Go Authors. All rights reserved.`
			`// Use of this source code is governed by a BSD-style`
			`// license that can be found in the LICENSE file.`

			`package b`

test: add new test case for 51219 that triggers the types2 issue The existing test for 51219 didn't actually trigger the types2 issue - I hadn't been able to minimize the test case yet properly. This new test case issue51219b.go now does trigger the types2 issue (it's only slightly different). Updates #51219 Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc Reviewed-on: https://go-review.googlesource.com/c/go/+/387814 Trust: Dan Scales <danscales@google.com> Reviewed-by: Robert Findley <rfindley@google.com> 2022-02-24 01:57:09 +00:00			`import (`
			`"./a"`
			`)`
cmd/compile: fix importers to deal with recursion through type constraints The code for issue #51219 reveals bugs in the types1 and types2 importers that can occur for recursive types that are recursive through the type constraint. The crash in the issue is caused by the types1 bug, which leads to the production of a type1 type which is incomplete and improperly has the HasTParam flag set. The bug in the types1 importer is that we were not deferring type instantiations when reading the type parameters, but we need to do that exactly to correctly handle recursion through the type constraint. So, the fix is to move the start of the deferrals (in the 'U' section of doDecl in typecheck/iimport.go) above the code that reads the type params. Once that bug is fixed, the test still crashes due to a related types2 importer issues. The problem is that t.SetConstraint(c) requires c to be fully constructed (have its underlying type set). Since that may not be done yet in the 'U' case in (*importReader).obj() in importer/iimport.go, we need to defer the call to SetConstraint() in that case, until we are done importing all the types. I added a test case with recursion through a type constraint that causes a problem that is fixed by the types1 importer change, though the error is not the same as in the issue. I added more types in the test case (which try to imitate the issue types more closely) the types2 bug, but wasn't able to cause it yet with the smaller test case. Fixes #51219 Change-Id: I85d860c98c09dddc37f76ce87a78a6015ec6fd20 Reviewed-on: https://go-review.googlesource.com/c/go/+/386335 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 2022-02-17 04:11:52 +00:00
test: add new test case for 51219 that triggers the types2 issue The existing test for 51219 didn't actually trigger the types2 issue - I hadn't been able to minimize the test case yet properly. This new test case issue51219b.go now does trigger the types2 issue (it's only slightly different). Updates #51219 Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc Reviewed-on: https://go-review.googlesource.com/c/go/+/387814 Trust: Dan Scales <danscales@google.com> Reviewed-by: Robert Findley <rfindley@google.com> 2022-02-24 01:57:09 +00:00			`// InteractionRequest is an incoming request Interaction`
cmd/compile: fix importers to deal with recursion through type constraints The code for issue #51219 reveals bugs in the types1 and types2 importers that can occur for recursive types that are recursive through the type constraint. The crash in the issue is caused by the types1 bug, which leads to the production of a type1 type which is incomplete and improperly has the HasTParam flag set. The bug in the types1 importer is that we were not deferring type instantiations when reading the type parameters, but we need to do that exactly to correctly handle recursion through the type constraint. So, the fix is to move the start of the deferrals (in the 'U' section of doDecl in typecheck/iimport.go) above the code that reads the type params. Once that bug is fixed, the test still crashes due to a related types2 importer issues. The problem is that t.SetConstraint(c) requires c to be fully constructed (have its underlying type set). Since that may not be done yet in the 'U' case in (*importReader).obj() in importer/iimport.go, we need to defer the call to SetConstraint() in that case, until we are done importing all the types. I added a test case with recursion through a type constraint that causes a problem that is fixed by the types1 importer change, though the error is not the same as in the issue. I added more types in the test case (which try to imitate the issue types more closely) the types2 bug, but wasn't able to cause it yet with the smaller test case. Fixes #51219 Change-Id: I85d860c98c09dddc37f76ce87a78a6015ec6fd20 Reviewed-on: https://go-review.googlesource.com/c/go/+/386335 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 2022-02-17 04:11:52 +00:00			`type InteractionRequest[T a.InteractionDataConstraint] struct {`
			`a.Interaction[T]`
			`}`