Support functional setFunctionBreakpoints command

[st0012]

Currently, DAP server responds to setFunctionBreakpoints command but it doesn't really do anything. This PR enables adding/removing method breakpoints.

Supported breakpoint types:

class Foo
  def foo
  end

  def self.bar
  end
end

foo = Foo.new

• Foo#foo - will stop at Foo's instance method foo
• Foo.bar - will stop at Foo's singleton method bar

This is not intentionally supported but currently it works:

• foo.foo - will stop at foo object's #foo method call

Condition is also supported:

Demos

Function Breakpoint

Function.breakpoints.mov

Function Breakpoint with Conditions

Function.breakpoints.with.condition.mov

[ko1]

I couldn't determine the specification about what is "function" breakpoints on DAP.
For example, what happens on "foo.bar" is given.

What happens?

[ko1]

Also do you receive the requests about this feature?

[st0012]

You can set a function breakpoint like this:

And it can work just like b f.baz in the console:

#35103:[>] {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[{"enabled":true,"id":"6642c99a-54b8-4bff-88eb-72647127d9cf","sessionData":{},"name":"f.baz"}]},"type":"request","seq":19}
#35103:[<] {"type":"response","command":"setFunctionBreakpoints","request_seq":19,"success":true,"message":"Success","body":{"breakpoints":[{"verified":true,"message":"#<DEBUGGER__::MethodBreakpoint:0x00007fc807868388 @sig_klass_name=\"f\", @sig_op=\".\", @sig_method_name=\"baz\", @klass_eval_binding=nil, @override_method=false, @klass=#<Foo:0x00007fc80787ab28>, @method=#<Method: Foo#baz() target.rb:6>, @cond_class=#<Class:#<Foo:0x00007fc80787ab28>>, @key=\"f.baz\", @deleted=false, @cond=nil, @command=nil, @path=nil, @tp=#<TracePoint:enabled>>"}]},"seq":22}
#35103:[>] {"command":"continue","arguments":{"threadId":1},"type":"request","seq":20}
#35103:[<] {"type":"response","command":"continue","request_seq":20,"success":true,"message":"Success","body":{"allThreadsContinued":true},"seq":23}
#35103:[<] {"type":"event","event":"stopped","body":{"reason":"breakpoint","description":" BP - Method  f.baz at target.rb:6","text":" BP - Method  f.baz at target.rb:6","threadId":1,"allThreadsStopped":true},"seq":24}

[st0012]

Also do you receive the requests about this feature?

I want this feature myself. And since it's marked as supported, I think we should make it work anyway.

[ko1]

I see.

• b foo.bar should be rejected on VSCode because it doesn't make sense.
• b foo.bar should be rejected on REPL if foo is not on the environment. (TODO)
• b foo#bar should be rejected on REPL too. (TODO)
• b Foo.bar can be allowed on VSCode and REPL (for singleton method which can be defined in future).

I'll rewrite them for 1.6.

[st0012]

should be rejected on VSCode because it doesn't make sense.

I don't understand why it needs to be rejected. If foo is presented in the scope, why not just create the breakpoint?
I know with VSCode it's not the same as b foo.bar. But the user can attach to the debugger with foo.bar selected, move the frame to where foo is defined, and toggle the foo.bar to create the breakpoint.

[ko1]

I don't understand why it needs to be rejected.

Please stop the program and re-start the debugging.

[st0012]

Sorry I'm not sure if I get the point. foo.bar is possible to achieve so I'm not sure why we need to reject it. And I also don't know how restart can solve it...?

[st0012]

@ko1 regarding that case, I don't mean we should support it. But since it works, I don't think it's a high priority to prohibit it. I do mark it as unintentional supported in the description though.

I also have added condition supports for it and uploaded 2 demos videos. I think it's ready for review now.

[st0012]

cc @ono-max

[ono-max]

For me, I'd prefer to use req_add_function_breakpoint(breakpoint) to match with req_add_breakpoint.

[st0012]

Because it can also remove breakpoints, I think it's better to use set. I prefer renaming other helpers instead, wdyt?

[ono-max]

If I have to say, I'd like to choose add. there are two options in this case.

If we align with DAP, set is better. Users who are familiar with DAP should understand it easily.
On the other hand, add and remove are better in the context of CDP.

When I design breakpoint method, I decided to use add and remove because they are more intuitive than set.

[ko1]

At the breakpoint, it is possible to set a BP for foo.bar. However

• 1. VSCode can set BPs before running the program. foo.bar is sent at the start, and it will be ignored. Furthermore, it can affect unintentional point. Also it runs any Ruby expression, so it should be limited.
• 2. When set this BP for the current scope at breakpoint, the configuration remains and after the termination of the debugger, restarting the debugger will use this information and cause same issue of 1.