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: compiler does not allow "direct binding" of function return values to `copy` arguments #15992

Open
momchil-velikov opened this Issue Jun 7, 2016 · 10 comments

Comments

Projects
None yet
7 participants
@momchil-velikov
Contributor

momchil-velikov commented Jun 7, 2016

go version devel +2f08888 Tue Jun 7 06:04:23 2016 +0000 linux/amd64

The spec allows "forwarding"/"direct binding" of return values to function arguments
https://golang.org/ref/spec#Calls

As a special case, if the return values of a function or method g are equal in number and individually
assignable to the parameters of another function or method f, then the call f(g(parameters_of_g)) will
invoke f after binding the return values of g to the parameters of f in order.

For the following program (https://play.golang.org/p/YEJSEfQLA8):

package main

import (
    "fmt"
)

func f(a []byte) ([]byte, []byte) {
    return a, []byte("abc")
}

func g(a []byte) ([]byte, string) {
    return a, "abc"
}

func main() {
    a := []byte{1, 2, 3}
    n := copy(f(a))
    fmt.Println(n, a)

    b := []byte{1, 2, 3}
    n = copy(f(b))
    fmt.Println(n, b)
}

the compiler issues messages

prog.go:17: missing arguments to copy
prog.go:21: missing arguments to copy

The same program passes when compiled via gotypes and gccgo.

@ianlancetaylor ianlancetaylor changed the title from cmd/compile: compiler does no allow "direct binding" of fucntion return values to `copy` arguments to cmd/compile: compiler does not allow "direct binding" of fucntion return values to `copy` arguments Jun 7, 2016

@ianlancetaylor ianlancetaylor added this to the Go1.8 milestone Jun 7, 2016

@josharian josharian changed the title from cmd/compile: compiler does not allow "direct binding" of fucntion return values to `copy` arguments to cmd/compile: compiler does not allow "direct binding" of function return values to `copy` arguments Jun 7, 2016

@quentinmit quentinmit added the NeedsFix label Oct 11, 2016

@rsc rsc modified the milestones: Go1.9, Go1.8 Oct 21, 2016

@griesemer griesemer modified the milestones: Go1.9Maybe, Go1.9 Jun 8, 2017

@griesemer

This comment has been minimized.

Contributor

griesemer commented Jun 8, 2017

Moving to 1.9Maybe. There are easy work-arounds and this is exceedingly rare in the first place.

@odeke-em

This comment has been minimized.

Member

odeke-em commented Jun 8, 2017

I actually wanted to work on this but I spent so much time but in vain trying to figuring out why ascompatet wasn't firing, so I moved on to the next bug.

@griesemer

This comment has been minimized.

Contributor

griesemer commented Jun 23, 2017

Unlikely to happen at this point. Moving to 1.10.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 18, 2017

cmd/compile also erroneously errors on

delete(func() (map[int]int, int) { return nil, 0 }())
@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 18, 2017

@odeke-em The error about wrong number of arguments to copy happens during typechecking. See case OCOPY in typecheck1.

For comparison, see case OCOMPLEX for how to correctly handle multi-valued function calls.

Well, almost. It fails to handle this case:

package p

var x interface{ g() (float64, float64) }
var _ = complex(x.g())
@odeke-em

This comment has been minimized.

Member

odeke-em commented Oct 18, 2017

Interesting, thanks for the debugging @mdempsky I was stumped before as to when it happened.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 18, 2017

@odeke-em I usually start by tracking down where the error message is being printed. In this case, "missing arguments to copy" only appears once in typecheck.go.

@odeke-em

This comment has been minimized.

Member

odeke-em commented Oct 18, 2017

Nice nice, same-ish here. See the thing though is I spent hours tracing through all the steps that I could but it led me for some reason down to astcomp*. Perhaps I should have done it not at 2AM :)

@griesemer griesemer modified the milestones: Go1.10, Go1.11 Nov 28, 2017

@griesemer

This comment has been minimized.

Contributor

griesemer commented Jun 4, 2018

Been like this forever. Not urgent (but shouldn't bee too hard, either). Moving to 1.12.

@griesemer griesemer modified the milestones: Go1.11, Go1.12 Jun 4, 2018

@odeke-em odeke-em self-assigned this Oct 18, 2018

@griesemer

This comment has been minimized.

Contributor

griesemer commented Oct 22, 2018

Moving to unplanned. This is not stopping anyone from getting work done.

@griesemer griesemer modified the milestones: Go1.12, Unplanned Oct 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment