Skip to content

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

Closed
findleyr opened this issue Aug 16, 2021 · 4 comments
Closed

go/types: add tests that exercise concurrent use #47729

findleyr opened this issue Aug 16, 2021 · 4 comments
Assignees
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@findleyr
Copy link
Member

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

@findleyr findleyr added this to the Go1.18 milestone Aug 16, 2021
@findleyr findleyr added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 16, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/349411 mentions this issue: go/types: eliminate Named.instPos

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]>
@ianlancetaylor
Copy link
Contributor

@findleyr This is in the 1.18 milestone; time to move to 1.19? Thanks.

@findleyr findleyr modified the milestones: Go1.18, Go1.19 Feb 11, 2022
@ianlancetaylor
Copy link
Contributor

@findleyr This is in the 1.19 milestone; time to move to 1.20? Or Backlog? Thanks.

@findleyr findleyr modified the milestones: Go1.19, Go1.20 Jun 24, 2022
@findleyr findleyr self-assigned this Nov 10, 2022
@findleyr findleyr modified the milestones: Go1.20, Go1.21 Nov 18, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/484540 mentions this issue: go/types: update TestStdlib to type-check concurrently

@golang golang locked and limited conversation to collaborators May 22, 2024
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
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
Status: Done
Development

No branches or pull requests

3 participants