Case where the breakpoint resolution algorithm dosen't correctly find the first debuggable location on a line

[derekxu16]

In the example program below, putting a breakpoint on line 2, starting a debug session, and then hitting "step over" twice results in the debugger being paused at the = at 3:12, and then hitting "step over" again results in the debugger being paused at 3:17. If a breakpoint is put on line 3 instead of line 2, then the debugger pauses at 3:22 when a debug session is started.

void main() {
  final a1 = ['a', 'b', 'c'];                // line 2
  final a2 = a1.map((c) => c.toLowerCase()); // line 3
  print(a2);
}

related to: Dart-Code/Dart-Code#5430

[derekxu16]

I looked into this and found that the way the breakpoint on line 3 is resolved actually follows our rules for breakpoint resolution, so it is not a bug, but we may want to modify those rules. Breakpoints currently get resolved at the first debuggable position within the innermost closure on the requested line. I think it would make sense to ditch the "innermost closure condition" and simply resolve a breakpoint at the first debuggable position on the requested line. I'm guessing you would prefer this as well @stan-at-work, but it would be great if you could give confirmation.

[stan-at-work]

I looked into this and found that the way the breakpoint on line 3 is resolved actually follows our rules for breakpoint resolution, so it is not a bug, but we may want to modify those rules. Breakpoints currently get resolved at the first debuggable position within the innermost closure on the requested line. I think it would make sense to ditch the "innermost closure condition" and simply resolve a breakpoint at the first debuggable position on the requested line. I'm guessing you would prefer this as well @stan-at-work, but it would be great if you could give confirmation.

I would also prefer this yes. 👍