-
Notifications
You must be signed in to change notification settings - Fork 18k
go/types: add tests that exercise concurrent use #47729
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
Labels
Milestone
Comments
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 <[email protected]> Run-TryBot: Robert Findley <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Robert Griesemer <[email protected]>
@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: |
mateusz834
pushed a commit
to mateusz834/tgoast
that referenced
this issue
Dec 31, 2024
In order to have some test coverage of concurrent use of the go/types APIs, update the Stdlib test to type-check concurrently. In combination with non-deterministic ordering, this should hopefully provide moderate test coverage of concurrent use. Also, remove the arbitrary 10ms timeout in short mode, in favor of simply not running. After this change, TestStdlib went from taking 16s on my laptop to 2s, in part because of the parallelism and in part because we are no longer type-checking twice (once for the import er, once for the test). Fixes golang/go#47729 Change-Id: Ie49743947ab2d5aec051c3d09ce045acf5b94ad4 Reviewed-on: https://go-review.googlesource.com/c/go/+/484540 Reviewed-by: Robert Griesemer <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Robert Findley <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
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: