Debugger bug introduced with v2.8.3

[fade2gray]

I initially discovered the problem when debugging a script using Step Into (F11) and encountering a FileDelete command. Making sure the said file hadn't somehow become read-only, and that it wasn't open in some other app, I reverted to v2.8.2 which resolved the problem.

The attached video better explains what was happening (I hope) pre and post v2.8.2.

Video starts with v2.8.2 before updating to v2.8.3.

DebuggerBug.mp4

[mark-wiemer]

Very strange. All that's changed is the icon. But yes, I can repro the issue. Let me try to rollback now in the short term. Apologies for not testing this.

[mark-wiemer]

:( 2.8.4 will be identical to 2.8.2, I guess. See microsoft/vsmarketplace#235

[mark-wiemer]

My mistake, I introduced some "refactors" to clean up the code, but they seem to have broken the debugger and maybe other features. Very sorry for this, I did some testing but obviously missed this somehow. See #135. I will revert the changes, publish 2.8.4, and then investigate.

[mark-wiemer]

Manual tests confirm this was introduced by #135

[mark-wiemer]

Definitely introduced by 0f9d15f Add ESLint and fix problems. I've restored the offending branch for investigation.

[mark-wiemer]

Trying to write a test to automatically detect this failure. I'll need to programmatically create a breakpoint. I found the command ID for this via searching the command label in keyboard shortcuts, then I found its only reference in the code here: editor.debug.action.conditionalBreakpoint

[mark-wiemer]

vscode.debug.addBreakpoints doesn't work as one might expect, it seems to be used internally by a debugger, not by VS Code itself. Sticking with conditionalBreakpoint for now.

[mark-wiemer]

Identified the root cause: src/debugger/struct/command.ts#Continue must have value step_into, it does not accept stepInto. This is probably documented somewhere, but I can't find it :/