Support collapsing stack frames

[DanTup]

Sometimes call stacks in the debugger contain a lot of frames from code that isn't the users (for example SDK code):

#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:42)
#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:46)
#2      HotRunner.validateReloadReport (package:flutter_tools/src/run_hot.dart:407)
#3      HotRunner._reloadSources.<anonymous closure> (package:flutter_tools/src/run_hot.dart:528)
#4      _rootRunUnary (dart:async/zone.dart:1128)
#5      _CustomZone.runUnary (dart:async/zone.dart:1012)
#6      _FutureListener.handleValue (dart:async/future_impl.dart:129)
#7      _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:636)
#8      _Future._propagateToListeners (dart:async/future_impl.dart:665)
#9      _Future._completeWithValue (dart:async/future_impl.dart:478)
#10     Future.wait.<anonymous closure> (dart:async/future.dart:392)
#11     _rootRunUnary (dart:async/zone.dart:1128)
#12     _CustomZone.runUnary (dart:async/zone.dart:1012)
#13     _FutureListener.handleValue (dart:async/future_impl.dart:129)
#14     _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:636)
#15     _Future._propagateToListeners (dart:async/future_impl.dart:665)
#16     _Future._complete (dart:async/future_impl.dart:468)
#17     _SyncCompleter.complete (dart:async/future_impl.dart:51)
#18     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:246)
#19     Isolate.reloadSources (package:flutter_tools/src/vmservice.dart:1047)
#20     _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:30)
#21     _rootRunUnary (dart:async/zone.dart:1128)
#22     _CustomZone.runUnary (dart:async/zone.dart:1012)
#23     _FutureListener.handleValue (dart:async/future_impl.dart:129)
#24     _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:636)
#25     _Future._propagateToListeners (dart:async/future_impl.dart:665)
#26     _Future._complete (dart:async/future_impl.dart:468)
#27     _SyncCompleter.complete (dart:async/future_impl.dart:51)
#28     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:246)

It would be good if we could somehow allow these to be collapsed so the user can focus on their own code, and only expand these if required.

Maybe it could even just be another presentationHint type for "unimportant" or "external" code, and VS Code can collapse consecutive frames with that hint, allowing them to be expanded by clicking?

[weinand]

@isidorn we could collapse subsequent "uninteresting" stackframes into one expandable, right?

[isidorn]

@weinand yes, this could be easily done since we already use a tree for representing stack frames

[weinand]

Then we should plan to implement this.

[isidorn]

Currently we have a presentationHint both on the Source and on the StackFrame.
This feature should be based on the presenatationHint on the StackFrame imo. We could use the word deemphasize since we already use that as the presentationHint value for the Source. To be consistent and hopefully not confusing. An alternative is to have the value of something which corresponds to the UI. Or simply presentationHint: collapsed

The questions is how to name the expando element which would expand all subsequent deemphasized sources?
Foreign Stack Frames
Other Stack Frames
Collapsed Stack Frames

Also note that these unimportant stack frames will be indented. Tree does not allow me to do variable indentation based on item type, only on item depth.

fyi @roblourens

[roblourens]

Do we differentiate between different types of frames that might be collapsed separately? For example, if I have code that is "skipped by skipFiles" and code that is "skipped by smartStep", it might make sense for these to be marked differently so they would be collapsed as separate groups. I'm not sure what else debuggers are using presentationHint for.

I can imagine it making sense to hide "smartStep" skipped frames entirely, since I never care about them, while "skipFiles" frames I may want to inspect but don't want them to be in my face.

Maybe the DA should be able to label the collapsed group with a label that describes what's in it.

And think about the case where the collapsed frames are at the top of the stack. e.g. I break on an exception in a "skipped" file. Chrome devtools will collapse the blackboxed frames at the top of the stack and focus the first non-blackboxed frame, and show the error at that non-blackboxed frame. I'm not sure whether I like that or not, typically in that case I end up expanding the frames and looking at the real line of code that errored. But it's worth thinking about different scenarios.