Skip to content
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

types2, go/types: repeated identical external instantiations of the same type will lead to different types #47103

Open
griesemer opened this issue Jul 9, 2021 · 5 comments
Assignees
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jul 9, 2021

Reminder issue:

Because we don't have a global type map for external
instantiations, instantiating the same type twice, independently but
with the same type arguments, will result in two different types. This
is not correct. We need to provide some form of context for external
instantiations (which means the importers). This is a separate issue,
not yet addressed.

cc: @findleyr, @danscales @mdempsky

@griesemer griesemer added this to the Go1.18 milestone Jul 9, 2021
@griesemer griesemer self-assigned this Jul 9, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Jul 9, 2021

Change https://golang.org/cl/333383 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: recursive substitution must terminate (bug fix)

@CRYPTOENFORCER

This comment was marked as off-topic.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jul 9, 2021

Is this still an issue with the InstantiateLazy API? That already requires passing in the Checker as an argument, I think to allow deduplication.

@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Jul 9, 2021

No, this is not an issue with InstantiateLazy, only with Instantiate which doesn't provide a *Checker or any other kind of context/environment.

gopherbot pushed a commit that referenced this issue Jul 9, 2021
…must terminate (bug fix)

When types2.Instantiate is called externally, no *Checker is provided and
substitution doesn't have access to Checker.typMap; and instantiation of
recursive generic types leads to an infinite recursion in subst.

There was a local subster.cache but it was only set and never used.
Replaced subster.cache with subster.typMap, which is set to the global
Checker.typMap if available, and set to a local map otherwise. This
prevents such infinite recursions. Added a simple test.

More generally, because we don't have a global type map for external
instantiations, instantiating the same type twice, independently but
with the same type arguments, will result in two different types. This
is not correct. We need to provide some form of context for external
instantiations (which means the importers). This is a separate but
related issue which is not yet addressed (filed #47103).

Change-Id: I541556c677db54f7396fd0c88c7467894dfcf2e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/333383
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Jul 9, 2021

Change https://golang.org/cl/333569 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: replace types2.Instantiate with Checker.Instantiate

gopherbot pushed a commit that referenced this issue Jul 13, 2021
…ate with Checker.Instantiate

Allow Checker.Instantiate to work with a nil *Checker receiver
(for now). This opens the door to passing in a *Checker at all
times.

Also, added a verify flag to Instantiate, InstantiateLazy, and
instance, to be able to control if constraint satisfaction should
be checked or not.

Removed types2.Instantiate.

For #47103.

Change-Id: Ie00ce41b3e50a0fc4341e013922e5f874276d282
Reviewed-on: https://go-review.googlesource.com/c/go/+/333569
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants