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

x/tools/go/analysis/passes/copylock: allows assignment of composite literal with a "lock" #43044

Open
ghananigans opened this issue Dec 7, 2020 · 6 comments
Labels
Analysis Issues related to static analysis (vet, x/tools/go/analysis) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@ghananigans
Copy link

ghananigans commented Dec 7, 2020

The copylocks checker does not complain about

var a nonCopyableType
...
a = nonCopyableType{}

but does complain about

var a nonCopyableType
var b nonCopyableType
...
a = b

(as expected).

nonCopyableType looks something like:

type nonCopyableType struct {
    _ sync.NoCopy

    ...
}

where sync.NoCopy is
https://github.com/google/gvisor/blob/a97ceec01bc464c9efa5d8140906c46f637e9002/pkg/sync/nocopy.go#L22

I think this is because of

func checkCopyLocksAssign(pass *analysis.Pass, as *ast.AssignStmt) {
which allows assignment with a rhs composite literal, while ignoring the lhs.

@stamblerre stamblerre changed the title copylocks allows assignment of composite literal with a "lock" x/tools/go/analysis/passes/copylock: allows assignment of composite literal with a "lock" Dec 7, 2020
@stamblerre
Copy link
Contributor

/cc @matloob

@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Dec 7, 2020
@gopherbot gopherbot added this to the Unreleased milestone Dec 7, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 7, 2020
@josharian
Copy link
Contributor

Writing a zero value is both safe and useful. I believe that this is working as intended.

@tamird
Copy link
Contributor

tamird commented Dec 8, 2020 via email

@josharian
Copy link
Contributor

It is.

@tamird
Copy link
Contributor

tamird commented Dec 8, 2020

What? How can that possibly be safe? This is reproducible on the playground: https://play.golang.org/p/ZW9TPnAnEcQ

@josharian
Copy link
Contributor

What? How can that possibly be safe?

Instead of rhetorical questions, it would help to be concrete. What is unsafe about it? As long as the write isn't concurrent (which is the race detector's domain), you are opting to reset the mutex to a clean, unlocked state.

@adonovan adonovan added the Analysis Issues related to static analysis (vet, x/tools/go/analysis) label Apr 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Analysis Issues related to static analysis (vet, x/tools/go/analysis) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

7 participants