Migrate `runtime.Callers/2`

[djui]

Given Slide 25 from talk: Mid-stack inlining in the Go compiler (external) it seems like errors.callers should migrate.

Basically: "Avoid FuncForPC, use CallersFrames".

[alfred-landrum]

Here's a related golang issue, including the documentation change that recommends using CallersFrames:
golang/go#19426

Here's a closed experimental PR that uses CallersFrames, ignoring backwards compatibility, but passing for 1.7 and tip:
#108

[davecheney]

I'd prefer to delay this until runtime.FuncForPC is deprecated, and even then, given the go 1 contract I'm not sure there is an issue to be fixed here. With that said, if runtime.Callers can provide a simpler or more complete API that the one we're currently hand rolling then that seems like a good basis for switching too it.

…

On Thu, 9 Mar 2017, 01:33 Alfred Landrum ***@***.***> wrote: Here's a golang issue with discussion about the issue, and the documentation change that recommends using CallersFrames: golang/go#19426 <golang/go#19426> Here's a closed experimental PR that uses CallersFrames, ignoring backwards compatibility, but passing for 1.7 and tip: #108 <#108> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAyLqCVV55bl6wuLUSQ3zZdRIwQ47ks5rjrwxgaJpZM4MVNSe> .

[ChrisHines]

We are exploring a similar migration over at go-stack/stack#13. Important links for reference:

• cmd/compile: enable mid-stack inlining golang/go#19348
• https://go-review.googlesource.com/c/37854/

[davecheney]

Is there anything to do here, the method is depreciated, but it won't be going away any time soon.

[ChrisHines]

It will probably be worth doing something for Go 1.9. From the draft release notes:

Tracebacks generated by the runtime and recorded in profiles are now accurate in the presence of inlining. To retrieve tracebacks programmatically, applications should use runtime.CallersFrames rather than directly iterating over the results of runtime.Callers.

Switching to runtime.CallersFrames will become critical once Go has mid-stack inlining, which seems likely in one of the next few releases. The proposal has been accepted.

[davecheney]

A good motivation.

…

On Sun, 18 Jun 2017, 01:59 Chris Hines ***@***.***> wrote: It will probably be worth doing something for Go 1.9. From the draft release notes: Tracebacks generated by the runtime and recorded in profiles are now accurate in the presence of inlining. To retrieve tracebacks programmatically, applications should use runtime.CallersFrames rather than directly iterating over the results of runtime.Callers. Switching to runtime.CallersFrames will become critical once Go has mid-stack inlining, which seems likely in one of the next few releases. The proposal has been accepted. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAyxFgCbgrDDXtdm3JCQh1zY1LpC3ks5sE_fvgaJpZM4MVNSe> .

[agnivade]

Hi everyone,

Just saw the 1.9 release notes and thought to check on this library (I use it regularly and its awesome).
Mid-stack inlining has landed in 1.9. https://tip.golang.org/doc/go1.9#callersframes.

I believe this would be a good time to make the shift to runtime.CallersFrames.

[alfred-landrum]

@davecheney - given the above rationale, would you be ready to consider a more polished version of my early PR, #108 ?