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

Jump to bottom

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

Open
findleyr opened this issue Aug 16, 2021 · 3 comments
Open

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

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

Comments

@findleyr
Copy link
Contributor

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
@findleyr findleyr mentioned this issue Aug 23, 2021
Closed
@gopherbot
Copy link

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
@findleyr
go/types: eliminate Named.instPos
bf26e43 
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>
@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@findleyr findleyr

Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
Release Status & Blockers (1.20)
Status: No status
Milestone
Go1.21
Development

No branches or pull requests
3 participants
@ianlancetaylor @gopherbot @findleyr