Dart-code: Warn users when there are breakpoints on SDK/Packages that won't be hit due to debug settings

[gaaclarke]

Seen result:
I can place breakpoints inside of my unit test and execution will pause correctly, but if I put a breakpoint in the framework, say packages/flutter/lib/src/widgets/scroll_physics.dart the breakpoint will not trigger.

Expected result:
I expect breakpoints in the framework to behave like breakpoints in the unit tests.

Seen system:
Dart Code Version: 3.10.1
VSCode: 1.44.2
Operating System: Mac OS X 10.14.6

Flutter Doctor:

[✓] Flutter (Channel unknown, 1.18.0-9.0.pre.66, on Mac OS X 10.14.6 18G2022, locale en-US)
    • Flutter version 1.18.0-9.0.pre.66 at /Users/aaclarke/dev/flutter
    • Framework revision 780d93bf38 (19 hours ago), 2020-05-04 17:18:41 -0700
    • Engine revision 4bcfae82c7
    • Dart version 2.9.0 (build 2.9.0-3.0.dev a69cb6d700)

Notes:

• If I use the debugger() function in my desired code, execution will pause but the stack trace inside of visual studio code will not include anything beyond the unit test.

[gaaclarke]

I was able to get the breakpoints to work by adding the following settings:

• Debug Sdk Libraries
• Debug External Libraries

Only doing Debug Sdk Libraries wasn't sufficient, I had to do both. I'm not sure what the benefit there is to turning these off. Seems like it should be on by default, or at least pop up a dialog if someone adds a breakpoint that won't be triggered.

[DanTup]

Only doing Debug Sdk Libraries wasn't sufficient, I had to do both.

This is expected, SDK here refers to the Dart SDK and built-in dart: libraries, where as Flutter is considered a package (package:flutter). I'll tweak the text on the descriptions for these settings to make that clearer.

I'm not sure what the benefit there is to turning these off. Seems like it should be on by default, or at least pop up a dialog if someone adds a breakpoint that won't be triggered.

When this setting was added, we prompted users at startup to ask which they'd rather have. Most people picked to debug "just my code" and eventually the prompt was removed (it's weird to pop up and ask about one specific setting when there are so many).

With this off, ehen an exception occurs in the framework, it will break the debugger where your code called into the framework. For example, if you have an assert that fails, you may consider it more useful to break in your code where the assert call is than deep inside the implementation of the assert.

To improve visibility and to make it easier to switch while debugging, v3.7 added a status bar toggle for quickly switching between these:

https://dartcode.org/releases/v3-7/#debug-mode-toggle

Hope this helps!

[DanTup]

or at least pop up a dialog if someone adds a breakpoint that won't be triggered.

This might be possible, I'll take a look - thanks!

[gaaclarke]

With this off, ehen an exception occurs in the framework, it will break the debugger where your code called into the framework.

Makes sense, thanks @DanTup. Also, in lieu of a warning we could consider just treating explicit breakpoints as exceptions to the settings, too. That might be easier. I think it's a pretty clear signal someone wants it to break there if they go through the trouble of adding the breakpoint.

[DanTup]

I'd prefer to prompt the user rather than silently change it, since it affects more than just breakpoints (otherwise we could just default it to on).

It's a bit more complicated than I expected though, as we usually look at the libraries URI to decide if a library is SDK/package, but when breakpoints are set we only have file paths (that is, if you F12 into an SDK library, you'll put the breakpoint in the full path to the SDK, but when we're setting which libraries are debuggable, we're looking for dart: libraries).

I'll think more about this and see what I can come up with.

[gaaclarke]

Thanks @DanTup, you won't need to change the value, just redefine what it means. The definition is the same except for this one addition "explicitly set breakpoints always break no matter where they are set". Given the information you have, that seems possible.

[DanTup]

just redefine what it means

That's unfortunately not possible. We don't control the breaking or stepping behaviour, it's all in the VM. All we get to do is (at startup) tell the VM "please enable debugging for these [...] libraries". This will have the effect of both preventing stepping into them and having breakpoints not work.

Therefore my plan is that while we're passing the breakpoints to the VM, we check whether they're user-code/SDK/external-package and if they are, but those settings are not enabled, we prompt the user to change their settings. This however, requires resolving the file paths to one of those categories.

I have some possible ideas, but I don't know how feasible they are, I need to do a little more testing. At its most basic, we could probably just detect if a breakpoint it outside of the open workspace at all, and assume that's likely either the SDK or a pub package, and show the prompt.

[DanTup]

Neither of my other ideas worked, so the best I could come up with for now is this when you have a breakpoint outside of your current workspace. If you already have them, this will appear at project open, but otherwise it'll appear as soon as you add the breakpoint:

It will only prompt once per session (and if you click Never Ask it won't ask again).