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
go/types: add tests that exercise concurrent use #47729
Labels
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
findleyr
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Aug 16, 2021
Change https://golang.org/cl/349411 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 14, 2021
We no longer need to use the nilness of Named.instPos to signal whether instance expansion has occurred, so remove it from the Named struct by instead closing over the instantiation position in the resolver. This means we cannot print instance markers for unexpanded instances: instances may escape the type checking pass without being fully expanded, and we can not check whether they have been expanded in a concurrency-safe way without introducing a more heavy-weight syncronization mechanism. With this change, instantiation should be concurrency safe, modulo bugs of course as we have little test coverage of concurrency (see #47729). Fixes #47910 Change-Id: Ifeef6df296f00105579554b333a44d08aae113c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/349411 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
@findleyr This is in the 1.18 milestone; time to move to 1.19? Thanks. |
@findleyr This is in the 1.19 milestone; time to move to 1.20? Or Backlog? Thanks. |
Change https://go.dev/cl/484540 mentions this issue: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
x/tools has tests that exercise concurrent use of go/types, but go/types itself does not. With the various lazy operations in go/types, it is easy to introduce race conditions. This has bitten us several times in the past (#47726, #47345, #44434, from recent memory).
We should add tests that exercise valid concurrent use of go/types.
CC @griesemer
The text was updated successfully, but these errors were encountered: