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
Closed

cmd/compile: failure to reject unused dot import #22072

mdempsky opened this issue Sep 27, 2017 · 4 comments

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky 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

@odeke-em odeke-em 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

@mdempsky mdempsky 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

@odeke-em odeke-em 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

@griesemer griesemer 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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.