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

cmd/vet: Vet incorrectly reports composite literal uses unkeyed fields on user defined types #6820

Closed
ncw opened this issue Nov 22, 2013 · 5 comments

Comments

Projects
None yet
3 participants
@ncw
Copy link
Contributor

commented Nov 22, 2013

What steps will reproduce the problem?

Create the test files like this (shell)

mkdir vet_bug
cd vet_bug
GOPATH=`pwd`
mkdir src
cd src
mkdir a
cat <<EOF > a/a.go
package a

type Tuple []string
EOF
cat <<EOF > main.go
package t

import "a"

var x = a.Tuple{"a", "b", "c"}
EOF
go build ./...
go vet ./...


This creates a directory structure like this with GOPATH set

vet_bug
└── src
    ├── a
    │   └── a.go
    └── main.go


What is the expected output?

Nothing

What do you see instead?

main.go:5: a.Tuple composite literal uses unkeyed fields

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

ubuntu linux/amd64

Which version are you using?  (run 'go version')

go version go1.2rc5 linux/amd64

../src/code.google.com/p/go.tools$ hg summary
parent: 552:898cd2875732 tip
 dashboard/builder: minor fixes and enhancements
branch: default
commit: (clean)
update: (current)

Please provide any additional information below.

If you define the Tuple type in the same file then vet doesn't complain about it.  For
vet to complain the definition needs to be in a different package.
@ncw

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2013

Comment 1:

That should be
export GOPATH=`pwd`
Of course!
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2013

Comment 2:

This behaviour is intentional.  Using field keys for a struct composite literal for a
struct type defined in a different package means that your composite literal is immune
to backward compatible changes in the imported package.  See the note on "struct
literals" in  http://golang.org/doc/go1compat .
For a type defined within the same package there are no concerns about backward
compatible changes, so vet doesn't warn about them.

Status changed to WorkingAsIntended.

@ncw

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2013

Comment 3:

But what I defined *wasn't* a struct type, it was a slice type which can't have
composite literals `type Tuple []string`
So I think this is a bug as there is no way of fixing the above code so that vet doesn't
moan about it.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2013

Comment 4:

Sorry, my mistake; I missed that that was a slice type.
The thing is, vet only looks at one package at a time.  It doesn't know that this is a
slice type.  So it warns.
According to the vet documentation, use the --composites=false flag to disable this
warning.
@ncw

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2013

Comment 5:

Ah OK that makes sense - thanks!

alban added a commit to alban/rkt that referenced this issue Jul 6, 2015

go vet: disable composites checks
Symptoms:

coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See rationale:
golang/go#6820

alban added a commit to alban/rkt that referenced this issue Jul 6, 2015

go vet: disable composites checks
Symptoms:

coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See rationale:
golang/go#6820

alban added a commit to alban/rkt that referenced this issue Jul 6, 2015

go vet: disable composites checks
Symptoms:

coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See rationale:
golang/go#6820

alban added a commit to alban/rkt that referenced this issue Jul 6, 2015

Semaphore: disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 6, 2015

Semaphore: disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 8, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 8, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 9, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 9, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 9, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

alban added a commit to endocode/rkt that referenced this issue Jul 10, 2015

Semaphore: Disable go vet on store/store_test.go
go vet works fine on newer versions (1.4.2) but it does not work on go
1.4 installed on Semaphore.

Symptoms:
coreos/rkt/store/store_test.go:286: types.Labels composite literal uses
unkeyed fields

See also: golang/go#6820

jonboulle added a commit to jonboulle/rkt that referenced this issue Jul 29, 2015

store: trick go vet into not complaining
`go vet` does not track types across packages and so assumes
types.Labels is a struct rather than a container; consequently, it
complains about unkeyed fields in store_test.go
To work around this, use a []types.Label and have go automatically
convert the type instead.

Re-enables go vet checking on Semaphore.

golang/go#6820

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.