Allow a stack frame with no source without saying "Unknown source"

[roblourens]

From #5552, looking at using stack frames with no source as a label for groups of async frames.

Currently when there's no source, they say "Unknown source" on the right. I think that either that label shouldn't be shown, or I should be able to mark a stack frame to have it not shown.

Also these frames are automatically 'deemphasized'. I'm not sure whether I would want that style. It needs to be obvious that these frames are async, and the point of deemphasize is to make a frame easy to ignore. I think that decision should be left up to the debug adapter.

[isidorn]

I agree that more of this should be moved to the debug adatper.
@roblourens is this something that is needed for feb, or should we tackle it in march?

[roblourens]

I won't do anything with it in Feb

[roblourens]

Instead of changing what happens when there's a frame with no source, I think it would be better to introduce a 'presentationHint' like 'label', which @weinand proposed in the other issue. It does make sense to show "Unknown source" for a normal frame with no source - that might be an error. A label frame is a specific thing that will work differently than other frames.

[isidorn]

I agree that we should introduce a new presentationHint.
Assigning this to @roblourens to add that presentationHint once that is supported please assign this issue back to me and I will pick it up on the vscode side.

Suggestion on how such a source should be shown are welcome here and in what way should it be specially treated.

fyi @weinand

[roblourens]

You're assigning to me to first have the debug adapter return the new presentationHint? Sure, I can do that today.

[weinand]

I'll add a 'frame' presentationHint to the DAP.

[isidorn]

@roblourens so if the stackFrame returns no source I will behave the same as before.
When an adapter returns a source with presentationHint 'frame' in what special way would you like it to be styled? Or just give me an easy way to repro this and I can make it look good

[weinand]

I don't think that we should use the presentationHint on Source for this. It is more appropriate to have something like this on StackFrame. I'm investigating...

[isidorn]

@weinand from my implementation point of view - I always expect a Source to be non null, so even if you introduce the presentaion hint on the stackFrame I will create a dummy source object with that presentation hint

[weinand]

@isidorn sure, you can create a dummy Source object as an implementation detail. But from the protocol perspective it sounds wrong to have the backend create dummy Source objects just to be able to specify the 'frame' presentationHint.

[roblourens]

I agree, I forgot that the presentationHint isn't actually on the frame.

[weinand]

I've created this "protocol addition" request: microsoft/vscode-debugadapter-node#106

[isidorn]

Great.
@roblourens let me know once node2 supports this so I can pick it up on my side

[weinand]

@isidorn I've added an optional presentationHint attribute to type type StackFrame.
The only supported value for now is label.
It is available in the latest.

[isidorn]

This is how we style stack frames which have a presentationHint = label
Note that I have hacked what the backend to always return presentationHint = 'label' in order to get his picture

[roblourens]

This is beautiful!
chrome-debug:

node unfortunately brings in some baggage, but this is still awesome:

Next up... collapse deemphasized frames? :)

[weinand]

@roblourens you could use a heuristic in the DA to hide those "well known" frames (independent from skipFiles)?
I don't think that anybody wants to ever debug the 5 deemphasized frames from above.

[roblourens]

That's not a bad idea. I could show a frame that says '5 collapsed frames' in the deemphasized style (or even using 'label'). And there could be a context menu item to toggle it.

It even might not be a bad thing to do for all skipFiles, especially when using async/await, because it generates a lot of garbage frames in user scripts. Collapse them by default, toggling works on the whole callstack and persists while stepping.

Cool how much we can do with minimal added vscode UI.

[weinand]

Yes, we should consider to have a generic "collapse/expand skipped frames" feature.
I was suggestion the "heuristic" only as a temporary measure (which does not require anything on the UI side).

[isidorn]

@roblourens great that you were able to connect all the dots! Maybe you could post a short gif showing of this niceness in the ux channel once you have it polished.