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: incorrect type error after "type int64 int32" #38882

Open
JohnReedLOL opened this issue May 5, 2020 · 5 comments
Open

cmd/compile: incorrect type error after "type int64 int32" #38882

JohnReedLOL opened this issue May 5, 2020 · 5 comments
Milestone

Comments

@JohnReedLOL
Copy link

@JohnReedLOL JohnReedLOL commented May 5, 2020

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

$ go version
go version go1.14.2 darwin/amd64

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/john-michaelreed/Library/Caches/go-build"
GOENV="/Users/john-michaelreed/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/john-michaelreed/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/john-michaelreed/sdk/go1.14.2"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/john-michaelreed/sdk/go1.14.2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/np/j2pvl5cd1mj8gkh66ml36j3m0000gn/T/go-build831703242=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Incorrect Error Message

What did you expect to see?

I expect to see "constant 100000000000 overflows main.int64".
Either that or the line "type int64 int32" shouldn't compile.

What did you see instead?

I see "constant 100000000000 overflows int64". That's incorrect because 100000000000 does not overflow int64. It overflows main.int64. Those are two different types.

@JohnReedLOL JohnReedLOL changed the title Wrong type error after "type int64 int32" Wrong type error after `type int64 int32` May 5, 2020
@JohnReedLOL JohnReedLOL changed the title Wrong type error after `type int64 int32` Wrong type error after "type int64 int32" May 5, 2020
@JohnReedLOL JohnReedLOL changed the title Wrong type error after "type int64 int32" Incorrect type error after "type int64 int32" May 5, 2020
@ianlancetaylor ianlancetaylor changed the title Incorrect type error after "type int64 int32" cmd/compile: incorrect type error after "type int64 int32" May 5, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 5, 2020

I suppose we could deliberately insert the package name when referring to a package scope variable that has the same name as a predeclared identifier. That seems a bit strange, but I guess it's not a common case.

@ianlancetaylor ianlancetaylor added this to the Backlog milestone May 5, 2020
@JohnReedLOL
Copy link
Author

@JohnReedLOL JohnReedLOL commented May 5, 2020

@ianlancetaylor It makes sense that if fmt.Printf says the type is main.int64, then the compiler should also say that the type is main.int64.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 5, 2020

Well, no, those are two different contexts. The reflect package uses a package name in front of every type name (other than predeclared types) because otherwise it would be ambiguous. The compiler does not normally use a package name in front of type names defined in the package being compiled, because a compiler error message is clearly in the context of the package being compiled.

@JohnReedLOL
Copy link
Author

@JohnReedLOL JohnReedLOL commented May 6, 2020

@ianlancetaylor Go's type declarations are kind of unintuitive. Like take this example:

Type declaration shadowing
It's not obvious what the underlying type is or where that type (in this case main.int64) is coming from. Like the first two variables of type main.int64 are 32 bit ints and the second two variables of type main.int64 are 16 bit ints.

I opened up a similar issue regarding type declarations, but this time with pointer types:
#38890

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 6, 2020

You're right, the compiler does generate two different types, both named main.int64. This doesn't have anything to do with the fact that the type is named int64. It happens for any other type too. The types are not the same, as you can see by comparing reflect.TypeOf(I1) and reflect.TypeOf(It3), but they have the same name. That doesn't seem ideal. I filed #38893.

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
You can’t perform that action at this time.