Issue #7051 has been reported by sam.saffron (Sam Saffron).

----------------------------------------
Feature #7051: Extend caller_locations API to include klass and bindings. Allow caller_locations as a method hanging off Thread. 
https://bugs.ruby-lang.org/issues/7051

Author: sam.saffron (Sam Saffron)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0


The new caller_locations api allows one to get label, base_label, path, lineno, absolute_path. 

I feel this API should be extended some what and cleaned up a bit. 

1. I think there should be complete parity with caller and backtrace APIs. 

As it stands caller_locations is a fine replacement for `caller`, however the same code responsible for `caller` is also responsible for Thread#backtrace. As it stands there is no equivalent Thread#backtrace_locations API that allows one to grab OO backtraces for a thread. 

For sampling profilers a common technique is to spin a thread that grabs stack traces from a profiled thread. 

I played around with some of this here: https://github.com/SamSaffron/stacktrace/blob/master/test/test_stacktrace.rb 

2. I think there should be a way to get the class the method belongs to where possible. 

At the moment you need to use something like ruby2ruby to determine the class of a frame in a backtrace. Getting the class is actually very important for auto-instrumentation techniques. A general approach is to grab stack traces, determine locations that seemed to be called a lot, and then instrument them. Trouble is, without a class it is very hard to pick a point to instrument. 

I got this working with my stacktrace gem so I think it is feasible.

3. Ability to grab bindings up the call chain

For some advanced diagnostic techniques it is very handy to grab bindings up the chain, that way you can print out local vars in a calling method and so on. It would be handy if this api exposed bindings. 

4. Naming and longer term deprecation of caller 

The name caller_locations to me feels a bit unnatural, as an API it is superior in all ways to the current caller, yet is far harder to type or remember. I am not really sure what it should be named but caller feels a bit wrong. Also it feels very tied to MRI returning RubyVM:::Backtrace::Location , Location seems to me in the wrong namespace. Is JRuby and Rubinius going to be expected to add this namespace? Is this going to be spec? 

Has any though been given to longer term deprecation of 'caller'. 

5. What about exceptions? 

Exception has no equivalent of caller_locations, for exceptions it makes much more sense to cut down on allocations and store a thinner stack trace object, in particular for the massively deep stacks frameworks like rails have. Then materialize the strings if needed on iteration through Exception#backtrace

    


-- 
http://bugs.ruby-lang.org/