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/compile: failure to reject unused dot import #22072

Closed
mdempsky opened this issue Sep 27, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@mdempsky
Copy link
Member

commented Sep 27, 2017

cmd/compile accepts this package, but it should be rejected with an error that import "bytes" is unused:

package p

import . "bytes"

var _ = struct{ Buffer int }{Buffer: 0}
@odeke-em

This comment has been minimized.

Copy link
Member

commented Sep 28, 2017

@mdempsky am sure you already know but the same applies when we import pretty much any package and have the same symbol matched and used in a struct e.g

import . "bytes"
import . "strconv"
import . "net/http"

var _ = struct {
        Server   int
        Reader   int
        NumError string
}{Reader: 0, NumError: "a", Server: 0}
@mdempsky

This comment has been minimized.

Copy link
Member Author

commented Sep 28, 2017

@odeke-em Yep. The problem is that when we're noding the Buffer: 0 composite literal element, we don't have enough information to know whether it's a struct literal (which means Buffer is just a raw symbol) or an array/slice/map literal (where Buffer can be a named object, like a const or variable). Currently, we parse it as a named object, and then later take just the name if we realize it's a struct literal.

The problem with this approach is when we access the named object that's been dot imported, we eagerly mark the import as used, even if it turns out later we didn't need the object.

@odeke-em

This comment has been minimized.

Copy link
Member

commented Dec 23, 2017

@mdempsky aha, turns out that @griesemer had already reported this bug back in September 2013 with #6428. How should we handle the dups?

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2017

Duplicate of #6428.

@griesemer griesemer closed this Dec 24, 2017

@golang golang locked and limited conversation to collaborators Dec 24, 2018

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.