You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently GotoTargetsArguments provides only source, line, and column. This is not enough to identify if a given line is valid for the user to move there. It should have threadId as an argument. This will allow the debugger to validate.
# test.pydeffoo():
print('A') # suppose thread 2 is stopped heredefbar():
print('B') # suppose thread 1 is stopped hereprint('C')
It is valid for thread 1 to move within the same block to print('C'). It is not valid for thread 2 to move to print('C'). There is no way to tell which thread the user wants to move from the arguments of gotoTargets request. The goto request will fail for thread 2, but this can be avoided.
For the screenshot below, I forced a blank targets response. This allows IDE to show changes to cursor indicating the move invalid
The text was updated successfully, but these errors were encountered:
Note: You have a screen shot of VS, but I don't think VS could provide you that information (at least not without a bunch of work) even if a thread id was added to the protocol as at the time that the UI asks the engine for the corresponding engine API (IDebugProgram2.EnumCodeContexts]) it doesn't know a thread.
Is there a problem with just failing the goto request instead?
It's what we're doing currently, so this is mostly about better UX.
It seems that most DAP implementations should be able to provide the thread in these circumstances, since they are issuing a goto request with that information immediately after. So I think it would be nice to have it in the protocol at least as an optional field, to encourage future implementations to provide it. The adapter can then try to do the best it can based on the information it has.
Currently
GotoTargetsArguments
provides onlysource
,line
, andcolumn
. This is not enough to identify if a given line is valid for the user to move there. It should havethreadId
as an argument. This will allow the debugger to validate.It is valid for
thread 1
to move within the same block toprint('C')
. It is not valid forthread 2
to move toprint('C')
. There is no way to tell which thread the user wants to move from the arguments ofgotoTargets
request. Thegoto
request will fail forthread 2
, but this can be avoided.For the screenshot below, I forced a blank targets response. This allows IDE to show changes to cursor indicating the move invalid
The text was updated successfully, but these errors were encountered: