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: internal compiler error: cannot handle alias type declaration (issue #25838): Callback #48353

Closed
swapx opened this issue Sep 13, 2021 · 8 comments

Comments

@swapx
Copy link

@swapx swapx commented Sep 13, 2021

What version of Go are you using (go version)?

$ go version
1.15.6

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Linux

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/USER/test/bin"
GOCACHE="/home/USER/test/.cache"
GOENV="/home/USER/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/USER/test/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/epetkas/test"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/app/vbuild/RHEL7-x86_64/go/1.15.6"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/app/vbuild/RHEL7-x86_64/go/1.15.6/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=
CGO_CFLAGS=-g -O2
CGO_CPPFLAGS=
CGO_CXXFLAGS=-g -O2
CGO_FFLAGS=-g -O2
CGO_LDFLAGS=-g -O2
PKG_CONFIG=pkg-config
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build941578384=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Please see https://play.golang.org/p/5_1QLRDWwFL

What did you expect to see?

$ go run cw_prototype.go

  1. Cert updated - cert 1
    Running callBack function - replace old cert with new cert: 'cert 1' in gRPC client
  2. Cert updated - cert 2
    Running callBack function - replace old cert with new cert: 'cert 2' in gRPC client
  3. Cert updated - cert 3
    Running callBack function - replace old cert with new cert: 'cert 3' in gRPC client
  4. Cert updated - cert 4
    Running callBack function - replace old cert with new cert: 'cert 4' in gRPC client
  5. Cert updated - cert 5
    Running callBack function - replace old cert with new cert: 'cert 5' in gRPC client

What did you see instead?

$ go run cw_prototype.go

command-line-arguments

.\cw_prototype.go:13:6: internal compiler error: cannot handle alias type declaration (issue #25838): Callback

Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new

@ALTree ALTree changed the title internal compiler error: cannot handle alias type declaration (issue #25838): Callback cmd/compile: internal compiler error: cannot handle alias type declaration (issue #25838): Callback Sep 13, 2021
@ALTree
Copy link
Member

@ALTree ALTree commented Sep 13, 2021

Note that go 1.15 is no longer supported, only the two most recent versions are (right now, 1.17 and 1.16).

Anyway the 1.17 compiler crashes on this too.

tip prints:

test.go:37:10: incompatible type: cannot use cw (variable of type *CertWatcher) as CertWatcherIf value
test.go:55:19: incompatible type: cannot use cw (variable of type *CertWatcher) as CertWatcherIf value

Which seems correct to me (so your reproducer does not compile). Possibly already fixed on tip? Do you have a reproducer that does compile?

Loading

@swapx
Copy link
Author

@swapx swapx commented Sep 13, 2021

Hello!
When I put the definition of the Interface in the beginning of the program, it solved the problem. Please have a look here: https://play.golang.org/p/GdQSiR2mUHf

Loading

@ALTree
Copy link
Member

@ALTree ALTree commented Sep 13, 2021

Thanks. So you don't have a program that crashes the tip compiler, I guess we can close this as fixed on tip(?)

Feel free to comment if I got it wrong.

Loading

@ALTree ALTree closed this Sep 13, 2021
@swapx
Copy link
Author

@swapx swapx commented Sep 13, 2021

Well, the first version of the program crashes the compiler. Is that an acceptable behaviour of the compiler ?

Loading

@ALTree
Copy link
Member

@ALTree ALTree commented Sep 13, 2021

This seems fixed on tip (so nothing more to do there), and the first version is a program that doesn't compile anyway, so even if it does crash 1.17, I think it may not be worth a backport (to 1.17.2 for example).

Loading

@swapx
Copy link
Author

@swapx swapx commented Sep 13, 2021

A solution may not be required for backporting, but it should be fixed in latest version of Golang I think. Or ?

Loading

@ALTree
Copy link
Member

@ALTree ALTree commented Sep 13, 2021

After a major version is released (for example go1.17), minor releases are issued (1.17.1, etc...) following this policy:

fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.

In my opinion this doesn't qualify for a backport, since it's not a "serious problem without a workaround", given that the code doesn't compile anyway. So it would be fixed in go1.18 when it is released.

Of course if we find a program that should compile (and it crashes the compiler), that would probably qualify for a backport.

Loading

@swapx
Copy link
Author

@swapx swapx commented Sep 13, 2021

If you fix it for go1.18 is fine for me.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants