Thanks to visit codestin.com
Credit goes to github.com

Skip to content

compiler/analysis/info.go function literal call site not recorded for later marking #955

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.

Sign up for GitHub

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

Jump to bottom
Closed
FrankReh opened this issue Jan 21, 2020 · 0 comments · Fixed by #1115
Closed

compiler/analysis/info.go function literal call site not recorded for later marking #955

FrankReh opened this issue Jan 21, 2020 · 0 comments · Fixed by #1115
Labels
bug NeedsReview A solution has been proposed that needs to be reviewed by GopherJS maintainers

Comments

@FrankReh
Copy link
Contributor

The function analysis.AnalyzePkg doesn't get the blocking right when a function literal calls another function that only later is determined to require blocking. The call site of the function literal is not retained for later handling.

A short main.go program that demonstrates the problem.

package main

import "runtime"

func main() {
	foo()
	println("main done")
}

// Problem: foo is not recognized as a blocking function.
//
// TLDR; function literals aren't handled identically to defined functions
// in analysis/info.go and a call stack is not kept for later use.
//
// Short cause analysis: the function literal called in foo is not determined
// to be blocking until later in analysis/info.go when it is determined that bar
// is blocking.  The FuncLit itself is recognized as blocking later on once bar
// has been analyzed, but not foo: while foo was being analyzed the call site
// stack within it was not saved for later use. So the call site effectively
// falls through and is left as unblocking, so foo is left as unblocking, so
// main is left as unblocking.
func foo() {
	func() { bar() }()
	println("foo done")
}

func bar() {
	runtime.Gosched()
}
FrankReh added a commit to FrankReh/gopherjs that referenced this issue Jan 21, 2020
@FrankReh
fixes blocking when using function literals
d99e3ec 
When a function literal is used that calls another function and
that other function has yet to be analyzed, the call site for
the function literal is not retained, so it's not processed later,
so the function that was calling the function literal is not made
blocking itself, when it should be.

A new field is used in info.go. It's name kept short to keep gofmt
from readjusting surrounding lines. It's not the most descriptive name
as it stands.

A short test case that demonstrates the problem can be found in
issue gopherjs#955.

Fixes gopherjs#955.
@FrankReh FrankReh mentioned this issue Jan 21, 2020
Closed
@nevkontakte nevkontakte added bug NeedsReview A solution has been proposed that needs to be reviewed by GopherJS maintainers labels Feb 20, 2021
nevkontakte added a commit to nevkontakte/gopherjs that referenced this issue Apr 19, 2022
@nevkontakte
Propagate blocking function information through function literal calls.
6c813e9 
When a function literal is used that calls another function and
that other function has yet to be analyzed, the call site for
the function literal is not retained, so it's not processed later,
so the function that was calling the function literal is not made
blocking itself, when it should be.

This change makes blocking status propagate through any number of
intermediate literal function calls.

This is a rebase of gopherjs#956.

Fixes gopherjs#955.

Co-authored-by: FrankReh
nevkontakte added a commit to nevkontakte/gopherjs that referenced this issue Apr 19, 2022
@nevkontakte @FrankReh
Propagate blocking function information through function literal calls.
49993f5 
When a function literal is used that calls another function and
that other function has yet to be analyzed, the call site for
the function literal is not retained, so it's not processed later,
so the function that was calling the function literal is not made
blocking itself, when it should be.

This change makes blocking status propagate through any number of
intermediate literal function calls.

This is a rebase of gopherjs#956.

Fixes gopherjs#955.

Co-authored-by: Frank Rehwinkel <[email protected]>
@nevkontakte nevkontakte mentioned this issue Apr 19, 2022
Merged
flimzy pushed a commit that referenced this issue Apr 19, 2022
@nevkontakte @FrankReh @flimzy
Propagate blocking function information through function literal calls.
09f3f46 
When a function literal is used that calls another function and
that other function has yet to be analyzed, the call site for
the function literal is not retained, so it's not processed later,
so the function that was calling the function literal is not made
blocking itself, when it should be.

This change makes blocking status propagate through any number of
intermediate literal function calls.

This is a rebase of #956.

Fixes #955.

Co-authored-by: Frank Rehwinkel <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug NeedsReview A solution has been proposed that needs to be reviewed by GopherJS maintainers
Projects
None yet
Milestone
No milestone
2 participants
@nevkontakte @FrankReh