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: compilation of Go 1.13 package fails when importing exported interface type with overlapping methods from Go 1.14 package #35437

Closed
mdempsky opened this issue Nov 7, 2019 · 6 comments

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Nov 7, 2019

At #6977 (comment), @bcmills says this should work:

$ cat a.go
package a

type a1 interface { A() }
type a2 interface { A() }
type A interface { a1; a2 }

$ cat b.go
package b

import "./a"

var _ a.A

$ go tool compile -lang=go1.14 a.go
$ go tool compile -lang=go1.13 b.go
/tmp/zz/a.go:5:24: duplicate method A
@mdempsky mdempsky added this to the Go1.14 milestone Nov 7, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Nov 7, 2019

@mdempsky

This comment has been minimized.

Copy link
Member Author

@mdempsky mdempsky commented Nov 7, 2019

Relatedly, type A = interface { a1; a2 } should also be okay: #6977 (comment)

@mdempsky

This comment has been minimized.

Copy link
Member Author

@mdempsky mdempsky commented Nov 7, 2019

I think adding something like case t.Pkg != nil && t.Pkg != localpkg: return to the switch in addMethod in expandiface should work. That should suppress duplicate method errors for imported interface types.

@griesemer

This comment has been minimized.

Copy link
Contributor

@griesemer griesemer commented Nov 7, 2019

[edited]

When compiling a Go 1.13 package, shouldn't we fail if we depend on a Go 1.14 feature via an import?

This is a corner-case because it can be "made to work" - but in general it's quite possible that a new language feature (contracts!) exposed via exports cannot be consumed by a package compiled for an older language version.

Summary: I agree with the argument in #6977 (comment): In this specific case, the combination of a1; a2 is done in package a and not "visible" in package b so this should be ok.

@mdempsky

This comment has been minimized.

Copy link
Member Author

@mdempsky mdempsky commented Nov 7, 2019

When compiling a Go 1.13 package, shouldn't we fail if we depend on a Go 1.14 feature via an import?

I'm not sure. We don't have much precedent for what it should do. For Go 1.9, we allowed a -lang=go1.9 package to export alias types, which could then be used by -lang=go1.8 packages. For Go 1.13, we didn't introduce any changes that could affect the type identity of exported identifiers.

I'm thinking the Go spec* needs to introduced the concept of Go language version, and it needs to be explained how differing language versions across packages should work. (* I'd also be fine with a separate document, like how the memory model is separately defined.)

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 8, 2019

Change https://golang.org/cl/205977 mentions this issue: cmd/compile: don't apply -lang=go1.X restrictions to imported packages

@gopherbot gopherbot closed this in b7d097a Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.