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

spec: clarify timing of nil-checks for defer/go statements #38634

Open
mdempsky opened this issue Apr 24, 2020 · 6 comments
Open

spec: clarify timing of nil-checks for defer/go statements #38634

mdempsky opened this issue Apr 24, 2020 · 6 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@mdempsky
Copy link
Member

mdempsky commented Apr 24, 2020

Test program: https://play.golang.org/p/rDWCdf_ha5w

This program tests various conditions where a deferred function call can panic "early" (i.e., at the time of the defer statement) or "late" (i.e., at the time the deferred function is actually invoked).

When compiled with cmd/compile, it prints "early late early \\ early late early \\ late".

When compiled with gccgo (edit: 8.0), it prints "late late early \\ late late early \\" and then crashes with a fatal error. (Edit: gccgo 10.0.1 prints "late late early \\ late late early \\ late".)

--

I think cases 2, 3, 5, and 6 where cmd/compile and gccgo agree are correctly implemented.

I think gccgo is wrong to fatally error on case 7. (If for no reason other than because the fatal error says "go of nil func value", but it's a defer statement.)

I'm unsure about cases 1, 4, and 7 otherwise though. I suspect they should all be "early" or all be "late" though.

/cc @griesemer @ianlancetaylor

@mdempsky mdempsky added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 24, 2020
@mdempsky mdempsky added this to the Unplanned milestone Apr 24, 2020
@erifan
Copy link

erifan commented Apr 24, 2020

With a relatively new version of gccgo, this program will not crash. My gccgo version:
$ gccgo --version
gccgo (GCC) 10.0.1 20200421 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But the print result is still "late late early \ late late early \".

@mdempsky
Copy link
Member Author

@erifan Thanks, apparently I was still using gccgo 8. Testing with 10.0.1, I agree it no longer crashes. Instead, the 7th test case prints "late", like cmd/compile.

@cuonglm
Copy link
Member

cuonglm commented Apr 24, 2020

I think case 7 should be early. The Go spec said:

the function value and parameters to the call are evaluated as usual and saved anew but the actual function is not invoked

So we should know f is nil at the end of defer statement.

@gopherbot

This comment has been minimized.

@go101
Copy link

go101 commented Mar 31, 2022

It looks gc has a similar self-inconsistency like gccgo

package main

import "fmt"

var n int

func log(test string, when *string) {
	recover()
	n++
	fmt.Printf("%d: %-24s // %s\n", n, test, *when)
}

type I interface{ M() }



type T struct{}

func (T) M() {}

var pt *T

func i1() {
	when := "early"
	defer log("defer i.M()", &when)

	var i I = pt
	defer i.M()
	when = "late"
}

func i2() {
	when := "early"
	defer log("defer I.M(i)", &when)

	var i I = pt
	defer I.M(i)
	when = "late"
}

func i3() {
	when := "early"
	defer log("f := i.M; defer f()", &when)

	var i I = pt
	f := i.M
	defer f()
	when = "late"
}

func main() {
	i1()
	i2()
	i3()
}

Outputs:

1: defer i.M()              // early
2: defer I.M(i)             // late
3: f := i.M; defer f()      // late

[Edit] If the i variable is global, then the self-inconsistency is gone.

package main

import "fmt"

var n int

func log(test string, when *string) {
	recover()
	n++
	fmt.Printf("%d: %-24s // %s\n", n, test, *when)
}

type I interface{ M() }



type T struct{}

func (T) M() {}

var pt *T

var i I = pt

func i1() {
	when := "early"
	defer log("defer i.M()", &when)

	//var i I = pt
	defer i.M()
	when = "late"
}

func i2() {
	when := "early"
	defer log("defer I.M(i)", &when)

	var i I = pt
	defer I.M(i)
	when = "late"
}

func i3() {
	when := "early"
	defer log("f := i.M; defer f()", &when)

	//var i I = pt
	f := i.M
	defer f()
	when = "late"
}

func main() {
	i1()
	i2()
	i3()
}

Outputs:

1: defer i.M()              // late
2: defer I.M(i)             // late
3: f := i.M; defer f()      // late

@go101
Copy link

go101 commented Mar 31, 2022

I think case 7 should be early. The Go spec said:

the function value and parameters to the call are evaluated as usual and saved anew but the actual function is not invoked

Doesn't this mean case 7 should be late instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants