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: Generics not properly working when been used with unsafe casts #51042

Closed
shoriwe opened this issue Feb 7, 2022 · 2 comments
Closed

Comments

@shoriwe
Copy link

@shoriwe shoriwe commented Feb 7, 2022

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

$ go version
go version go1.18beta2 windows/amd64

Does this issue reproduce with the latest release?

It should reproduce with go1.18beta2

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

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\?\AppData\Local\go-build
set GOENV=C:\Users\?\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\?\go\pkg\mod
set GONOPROXY=*
set GONOSUMDB=*
set GOOS=windows
set GOPATH=C:\Users\?\go
set GOPRIVATE=*
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\?\sdk\go1.18beta2
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\?\sdk\go1.18beta2\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.18beta2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\?\AppData\Local\Temp\go-build1818620206=/tmp/go-build -gno-record-gcc-switches

What did you do?

I was testing the generics feature to simplify the direct transformation of a slice sequence to an integer type.

Everything works fine in the int to bytes direction but the compiler is unable to properly compile the generic function that transform bytes to int.

package main

import (
	"constraints"
	"fmt"
	"unsafe"
)

func IntToBytes[T constraints.Integer](i T) []byte {
	return (*(*[8]byte)(unsafe.Pointer(&i)))[:unsafe.Sizeof(i)]
}

// This function is the one that is not working.
func BytesToInt[T constraints.Integer](b []byte) T {
	return *(*T)(unsafe.Pointer(&b[0]))
}

func main() {
	bs := IntToBytes(-387)
	fmt.Println(int64(BytesToInt(bs))) // The compiler is unable to properly create a generic from this
}

I know that those kind of transformations are possible because this example works fine:

package main

import (
	"constraints"
	"fmt"
	"unsafe"
)

func IntToBytes[T constraints.Integer](i T) []byte {
	return (*(*[8]byte)(unsafe.Pointer(&i)))[:unsafe.Sizeof(i)]
}

// I was expecting something like this by the compiler
func BytesToInt(b []byte) int64 {
	return *(*int64)(unsafe.Pointer(&b[0]))
}

func main() {
	bs := IntToBytes(int64(-387))
	fmt.Println(BytesToInt(bs))
}

What did you expect to see?

I expect to see the correct compilation of the program.

What did you see instead?

The compilation error:

cannot infer T
@shoriwe shoriwe changed the title affected/package: affected/package: Generics not properly working when been used with unsafe casts Feb 7, 2022
@shoriwe shoriwe changed the title affected/package: Generics not properly working when been used with unsafe casts Generics not properly working when been used with unsafe casts Feb 7, 2022
@shoriwe shoriwe changed the title Generics not properly working when been used with unsafe casts cmd/compile: Generics not properly working when been used with unsafe casts Feb 7, 2022
@beoran
Copy link

@beoran beoran commented Feb 7, 2022

The compiler cannot infer T for BytesToInt because none of the parameters are of type T. Note that the T for BytesToInt is not the same T as the one for IntToBytes. The compiler is correct to give this error. You can do it differently like in the example below.

https://gotipplay.golang.org/p/y_X_D1Iinq9

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 7, 2022

Thanks. Closing because this is not a bug.

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

No branches or pull requests

3 participants