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.

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

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
Closed

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

ncw opened this issue Nov 22, 2013 · 5 comments
Labels
FrozenDueToAge

Comments

@ncw
Copy link
Contributor

ncw 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
Copy link
Contributor Author

ncw commented Nov 22, 2013

Comment 1:

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

@ianlancetaylor
Copy link
Member

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
Copy link
Contributor Author

ncw 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
Copy link
Member

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
Copy link
Contributor Author

ncw 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
@alban
go vet: disable composites checks
f06c8ad 
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
@alban
go vet: disable composites checks
6cf06f5 
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
@alban
go vet: disable composites checks
a6729f3 
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
@alban
Semaphore: disable go vet on store/store_test.go
4208230 
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
@alban
Semaphore: disable go vet on store/store_test.go
38e18a9 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
d45062e 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
b956204 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
7b65d86 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
455fff8 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
a30fe3d 
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
@alban @krnowak
Semaphore: Disable go vet on store/store_test.go
fe28e38 
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 alban mentioned this issue Jul 15, 2015
Closed
jonboulle added a commit to jonboulle/rkt that referenced this issue Jul 29, 2015
@jonboulle
store: trick go vet into not complaining
cc9e6de 
`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
@jonboulle jonboulle mentioned this issue Jul 29, 2015
Merged
@juliusv juliusv mentioned this issue Sep 18, 2015
Merged
@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

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