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
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@benjaminjkraft
Copy link

(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

CC @griesemer

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 21, 2020
@ianlancetaylor ianlancetaylor added this to the Go1.15 milestone Feb 21, 2020
@griesemer griesemer self-assigned this Feb 21, 2020
@griesemer
Copy link
Contributor

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 .

@gopherbot
Copy link
Contributor

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

@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 23, 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.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants