Skip to content

go/types: make instantiation concurrency-safe #47910

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.

Sign up for GitHub

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
Closed
findleyr opened this issue Aug 23, 2021 · 5 comments
Closed

go/types: make instantiation concurrency-safe #47910

findleyr opened this issue Aug 23, 2021 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@findleyr
Copy link
Member

findleyr commented Aug 23, 2021 •
edited
Loading

Type instantiation is currently not concurrency-safe in go/types:

  • instances are expanded lazily.
  • instantiation hashing uses a package-local instanceHashing variable

See also #47729: the only reason this hasn't triggered test failures due to data races is that we lack test coverage for concurrent use in go/types, and x/tools is not yet exercising type instantiation.

CC @griesemer
@findleyr findleyr changed the title go/types: go/types: make instantiation concurrency-safe Aug 23, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/344390 mentions this issue: go/types: implement deduplication of instances using the Environment

@findleyr findleyr mentioned this issue Aug 23, 2021
Closed
@toothrot toothrot added this to the Backlog milestone Aug 24, 2021
@toothrot toothrot added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 24, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/346557 mentions this issue: go/types: eliminate typeHashing global variable

@timothy-king
Copy link
Contributor

This may be a concern for x/tools/go/ssa. Building for each package is done in its own go routine. Each will likely be instantiating types.

gopherbot pushed a commit that referenced this issue Sep 1, 2021
@findleyr
go/types: eliminate typeHashing global variable
5cd1b84 
This is a port of CL 345929 to go/types. It is also a step toward making
instantiation concurrency-safe.

Also fix some whitespace in instantiate.go.

Updates #47910

Change-Id: Icdeb227cb83eee15da6db90daab294c8c55db601
Reviewed-on: https://go-review.googlesource.com/c/go/+/346557
Trust: Robert Findley <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>
TryBot-Result: Go Bot <[email protected]>
@findleyr findleyr modified the milestones: Backlog, Go1.18 Sep 9, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/349410 mentions this issue: go/types: merge Named type loading and expansion

@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
@findleyr
go/types: merge Named type loading and expansion
2933c45 
Named type expansion and loading were conceptually similar: a mechanism
for lazily resolving type information in a concurrency-safe manner.
Unify them into a 'resolve' method, that delegates to a resolver func to
produce type parameters, underlying, and methods.

By leveraging the sync.Once field on Named for instance expansion, we
get closer to making instance expansion concurrency-safe, and remove the
requirement that instPos guard instantiation. This will be cleaned up
in a follow-up CL.

This also fixes #47887 by causing substituted type instances to be
expanded (in the old code, this could be fixed by setting instPos when
substituting).

For #47910
Fixes #47887

Change-Id: Ifc52a420dde76e3a46ce494fea9bd289bc8aca4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/349410
Trust: Robert Findley <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Robert Griesemer <[email protected]>
@findleyr findleyr mentioned this issue Sep 30, 2021
Closed
@golang golang locked and limited conversation to collaborators Sep 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@toothrot @timothy-king @gopherbot @findleyr