TracePoint: Support .trace

[olleolleolle]

This issue records the fact that TracePoint.trace is not supported. It does a combined instantiation and enabling of a TracePoint instance.

The JRuby extension TracePoint.java seems not to implement .trace and .stat

Workaround: JRuby's TracePoint has .new. and #enable. Use TracePoint.new and then #enable the resulting TracePoint instance.

Environment

$ jruby -v
jruby 9.1.13.0 (2.3.3) 2017-09-06 8e1c115 Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [darwin-x86_64]
$ uname -a
Darwin gungnir.lan 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

Expected Behavior

• I expect that TracePoint.trace instantiates and enables a TracePoint.

Example script to run:

TracePoint.trace(:call) { puts 'Hi' }

Example execution:

irb(main):001:0> TracePoint.trace(:call) { puts 'Hi' }
Hi
Hi
Hi
Hi
Hi
Hi
Hi
=> #<TracePoint:enabled>
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi
Hi

Actual Behavior

A NoMethodError is raised.

irb(main):002:0> TracePoint.trace(:call) { puts 'Hi' }
NoMethodError: undefined method `trace' for TracePoint:Class
Did you mean?  trace_var
               trap
	from org/jruby/RubyBasicObject.java:1657:in `method_missing'
	from (irb):2:in `<eval>'
	from org/jruby/RubyKernel.java:994:in `eval'
	from org/jruby/RubyKernel.java:1292:in `loop'
	from org/jruby/RubyKernel.java:1114:in `catch'
	from org/jruby/RubyKernel.java:1114:in `catch'
	from /Users/olle/.rubies/jruby-9.1.13.0/bin/irb:13:in `<main>'

[headius]

Wanna just throw the workaround into a bit of Ruby for a PR? core/src/main/ruby has the Ruby bits of JRuby.

[olleolleolle]

Thanks. Currently bowling, badly, but I’m giving this a shot later.

[headius]

Interestingly this exposed a small bug I had forgotten about: we don't actually trace the return from "c" functions if the trace was enabled mid-call. So the output now doesn't even have a return event 😢

I was unable to find a bug for this, so it must not be a big concern for anyone using tracing (e.g. set_trace_func has been used for a long time but nobody complained that it didn't trace itself returning). In any case, I think omitting the event is still better than emitting the "wrong" event, so we'll stick with this.