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

go/types: reported type of call to make() depends on whether argument is a const or var #37349

Closed
benjaminjkraft opened this issue Feb 21, 2020 · 3 comments
Assignees
Milestone

Comments

@benjaminjkraft
Copy link

@benjaminjkraft benjaminjkraft commented Feb 21, 2020

(Issue template below; in short this repros on 1.13 and tip.)

The documentation of go/types says:

    // For (possibly parenthesized) identifiers denoting built-in
    // functions, the recorded signatures are call-site specific:
    // if the call result is not a constant, the recorded type is
    // an argument-specific signature. Otherwise, the recorded type
    // is invalid.

For make() the signature seems a bit too call-site specific: it depends on whether the len and cap arguments are consts or vars. If the arguments are constant (e.g. make([]int, 10)), the type is something plausible: func([]int, int) []int. But if an argument is a variable (e.g. var length = 10; make([]int, 10)) the type is different, and strange: func([]int) []int. In particular, while it's arguable whether any of these types "make sense", this means the (non-variadic) function has more arguments than its supposed type's parameters, which is confusing to a static analysis. (Of course, Go itself is fine with it.)

The following more complete example repros on both play.golang.org and tip.golang.org.

It looks like this issue goes all the way back to golang/tools@0c45220 when this behavior of go/types was added -- in the code sizes is the number of constant arguments.

I'm not sure if fixing this would be considered a compatibility break; if not it could be documented as a bug.

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

$ go version
go version go1.13.5 linux/amd64

(also repros on tip.golang.org)

Does this issue reproduce with the latest release?

yes, latest and tip

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/benkraft/.cache/go-build"
GOENV="/home/benkraft/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/benkraft/.go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/benkraft//go.mod"
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/g
o-build562912148=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://play.golang.org/p/GYZrAdOnfff

What did you expect to see?

builtin make has type func([]int, int, int) []int
builtin make has type func([]int, int, int) []int
builtin make has type func([]int, int, int) []int
builtin make has type func([]int, int, int) []int

What did you see instead?

builtin make has type func([]int, int) []int
builtin make has type func([]int) []int
builtin make has type func([]int, int) []int
builtin make has type func([]int, int, int) []int
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 21, 2020

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Feb 23, 2020

This is just a bug. Fix forthcoming.

Also, it turns out that it doesn't report the correct types for non-constant non-integer arguments. Filed separate issue #37393 .

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 23, 2020

Change https://golang.org/cl/220584 mentions this issue: go/types: report correct number of arguments for make() built-in calls

Loading

@gopherbot gopherbot closed this in 151ccd4 Feb 24, 2020
@golang golang locked and limited conversation to collaborators Feb 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants