[dexter] Correctly identify stop-reason while driving VisualStudio #94754
Conversation
Prior to this patch VisualStudio._get_step_info incorrectly identifies the reason the debugger has stopped. e.g., stepping through a program would be reported as a StopReason.Breakpoint rather than StopReason.Step. Fix. Not test added as there are no VisualStudio tests (tested locally).
|
✅ With the latest revision this PR passed the Python code formatter. |
| @@ -307,6 +307,30 @@ def set_current_stack_frame(self, idx: int = 0): | |||
| ) | |||
| ) | |||
|
|
|||
| def _translate_stop_reason(self, reason): | |||
| # https://learn.microsoft.com/en-us/dotnet/api/envdte.dbgeventreason?view=visualstudiosdk-2022 | |||
| if reason == 1: # dbgEventReasonNone | |||
There was a problem hiding this comment.
Can those magic values (1, 9, 8, ...) be replace for some named constants?
There was a problem hiding this comment.
I can't find a way to get them out of the DTE interface. I could name the constants myself, but I'm not sure that really adds anything over what I've got here since they're only used in this one place. wdyt?
There was a problem hiding this comment.
May be something like:
dbgEventReasonNone = 1
dbgEventReasonGo = 2
...
if reason == dbgEventReasonNone:
...
Basically is the same code, but I think it is easy to read.
Otherwise LGTM.
There was a problem hiding this comment.
I don't have strong opinions, but in general even if it's only going to be used once I think it's probably better to have something like class VSDebugEventReason(IntEnum): with the correct values added to it.
Prior to this patch VisualStudio._get_step_info incorrectly identifies the reason the debugger has stopped. e.g., stepping through a program would be reported as a StopReason.Breakpoint rather than StopReason.Step.
Fix. No test added as there are no VisualStudio tests (tested locally).