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

runtime: strongly encourage using CallersFrames over FuncForPC with Callers result #19426

Closed
cespare opened this issue Mar 6, 2017 · 4 comments
Milestone

Comments

@cespare
Copy link
Contributor

cespare commented Mar 6, 2017

Go 1.7 introduced the CallersFrames API:

The new function CallersFrames translates a PC slice obtained from Callers into a sequence of frames corresponding to the call stack. This new API should be preferred instead of direct use of FuncForPC, because the frame sequence can more accurately describe call stacks with inlined function calls.

I understand that in Go 1.9, mid-stack inlining will make the results significantly worse for callers that are still using FuncForPC instead of CallersFrames. However, in the runtime documentation I don't see anything to steer the user towards one or the other.

Should we mark Func and FuncForPC as deprecated? Is there some situation to use them instead of CallersFrames?

@ianlancetaylor @aclements @davidlazar

@cespare cespare added this to the Go1.9 milestone Mar 6, 2017
@cespare
Copy link
Contributor Author

cespare commented Mar 6, 2017

(I guess that the Callers doc itself does say "To easily look up file/line information for the call sequence, use Frames.")

@aclements
Copy link
Member

Yes, the documentation should definitely steer people more strongly in the right direction than it does now. Thanks for creating an issue to track this.

@aclements aclements self-assigned this Mar 6, 2017
@gopherbot
Copy link

CL https://golang.org/cl/37726 mentions this issue.

@ianlancetaylor
Copy link
Contributor

FuncForPC should not in general be used with values returned by Callers or Caller, but it is still meaningful and has no replacement for other uses. For example, the use in funcName and methodName in reflect/value.go is entirely legitimate.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants