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

Jump to bottom

cmd/gc: inconsistent definition during type import #6513

Closed
dsymonds opened this issue Sep 30, 2013 · 7 comments
Closed

cmd/gc: inconsistent definition during type import #6513

dsymonds opened this issue Sep 30, 2013 · 7 comments
Labels
FrozenDueToAge
Milestone
Go1.2

Comments

@dsymonds
Copy link
Contributor 

This required three packages:
  A: defines an exported struct type T with an embedded field of a builtin type (e.g. "int", "error")
  B: imports "A" and embeds A.T in its own exported struct type U
  C: imports both "A" and "B"

I have created a sample in https://golang.org/cl/14115043. When you apply it to
a go tree, and run "go install expvar" you will get
# expvar
expvar/expvar.go:30: inconsistent definition for type io.Exported during import
        struct { int } (in "io")
        struct { int } (in "net/http")

This does *not* happen with Go 1.1, so is a regression.
@remyoudompheng
Copy link
Contributor

Comment 1:

I have bisected it to 
changeset:   15205:6a028d6b7222
user:        Rémy Oudompheng <oudomphe@phare.normalesup.org>
date:        Sat Dec 22 19:16:31 2012 +0100
summary:     cmd/gc: fix wrong interaction between inlining and embedded builtins.
so it is certainly present in Go 1.1 (but not Go 1.0). Can you check again ?

@dsymonds
Copy link
Contributor Author

Comment 2:

Hmm. Interesting. I just did a fresh checkout of go1.1.2 and it's broken there too. Also
at go1.1.1. Yet my original test case is fine with go1.1.1 and broken with tip, so I
don't know what's going on there. Perhaps my test case is subtly different and no longer
highlights the regression.
Either way, there's still a bug that seems worth fixing, and it sounds like you're on
the culprit.

@remyoudompheng
Copy link
Contributor

Comment 3:

Can you bisect the commit that triggers the regression with your original test case?
It is essentially impossible to miss the bug: your minimal example can be even
simplified by saying B is:
package b
import "a"
var U a.T
even without embedding. So maybe you had something shadowing the original bug?

@dsymonds
Copy link
Contributor Author

Comment 4:

Unfortunately it is quite difficult to bisect. I can if needed, but
would prefer to merely test potential fixes.

@remyoudompheng
Copy link
Contributor

Comment 5:

Please try https://golang.org/cl/14188044

Status changed to Started.

@dsymonds
Copy link
Contributor Author

dsymonds commented Oct 1, 2013

Comment 6:

That fixed my original problem, thanks!

@rsc
Copy link
Contributor

rsc commented Oct 2, 2013

Comment 7:

I submitted Remy's CL but forgot to add "Fixes issue #6513".

Status changed to Fixed.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2 label Apr 14, 2015
@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
Go1.2
Development

No branches or pull requests
4 participants
@dsymonds @rsc @remyoudompheng @gopherbot