[ruby-core:90321] [Ruby trunk Bug#15303] Return tracepoint doesn't fire when tailcall optimization is applied

[ko1@atdot.net]

Issue #15303 has been updated by ko1 (Koichi Sasada).


or `raise` on `return_value` ?

it is irregular case. I think tailcall is not normal call (it is same as a method call by lexicial).

```
foo() # tailcall
```

we can see:

```
return_and_call(:foo)
```

and nobody think it is strange.

in other words, using tailcall, we can define it as "transformation from former syntax to latter syntax~ we can think.

I want to know the real issue by this spec.

I want to know the 

----------------------------------------
Bug #15303: Return tracepoint doesn't fire when tailcall optimization is applied
https://bugs.ruby-lang.org/issues/15303#change-75426

* Author: alanwu (Alan Wu)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.6.0dev (2018-11-14 trunk 65727) [x86_64-darwin17]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
After a tailcall, the "return" tracepoint event is only fired once. Normally, after a call at the end of a method, the return event is fired twice, once for the callee returning and once for the caller returning.
The following script outputs 
~~~
:call
:call
:call
:return
~~~

~~~ ruby
method_source = <<-RB
def toy(n)
   return if n == 2
   toy(n+1)
end
RB

iseq = RubyVM::InstructionSequence.compile(method_source, tailcall_optimization: true)
#puts iseq.disasm
iseq.eval

trace = TracePoint.new(:call, :return) do |tp|
    p tp.event
end

trace.enable
toy(0)
~~~

The "return" event behaves more like a "stack frame pop" event currently. I don't think it's feasible/desirable to have the same behavior when TCO is applied, but it would be nice if there was some way for the tracepoint to know a tail call is going to happen.
I'm raising this issue because the popular debugger "byebug" relies on these events to track execution in various stack frames. https://github.com/deivid-rodriguez/byebug/issues/481
Forwardable explicitly uses TCO which triggers this issue.




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