intel/llvm
1
0
Fork 0
mirror of https://github.com/intel/llvm.git synced 2026-01-23 07:58:23 +08:00
Code Issues Packages Projects Releases Wiki Activity

[LLDB-DAP] SBDebugger don't prefix title on progress updates (#124648)

Browse Source 
In my last DAP patch (#123837), we piped the DAP update message into the
update event. However, we had the title embedded into the update
message. This makes sense for progress Start, but makes the update
message look pretty wonky.


![image](https://github.com/user-attachments/assets/9f6083d1-fc50-455c-a1a7-a2f9bdaba22e)

Instead, we only use the title when it's the first message, removing the
duplicate title problem.

![image](https://github.com/user-attachments/assets/ee7aefd1-1852-46f7-94bc-84b8faef6dac)
This commit is contained in:
Jacob Lalonde
2025-03-05 12:02:44 -08:00
committed by GitHub
parent 2bbe30bf35
commit 02f024ca97
4 changed files with 246 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
lldb/bindings/interface/SBProgressDocstrings.i
View File

@@ -11,7 +11,48 @@ The Progress class helps make sure that progress is correctly reported
and will always send an initial progress update, updates when
Progress::Increment() is called, and also will make sure that a progress
completed update is reported even if the user doesn't explicitly cause one
to be sent.") lldb::SBProgress;
to be sent.
Progress can either be deterministic, incrementing up to a known total or non-deterministic
with an unbounded total. Deterministic is better if you know the items of work in advance, but non-deterministic
exposes a way to update a user during a long running process that work is taking place.
For all progresses the details provided in the constructor will be sent until an increment detail
is provided. This detail will also continue to be broadcasted on any subsequent update that doesn't
specify a new detail. Some implementations differ on throttling updates and this behavior differs primarily
if the progress is deterministic or non-deterministic. For DAP, non-deterministic update messages have a higher
throttling rate than deterministic ones.
Below are examples in Python for deterministic and non-deterministic progresses.
deterministic_progress1 = lldb.SBProgress('Deterministic Progress', 'Detail', 3, lldb.SBDebugger)
for i in range(3):
deterministic_progress1.Increment(1, f'Update {i}')
# The call to Finalize() is a no-op as we already incremented the right amount of
# times and caused the end event to be sent.
deterministic_progress1.Finalize()
deterministic_progress2 = lldb.SBProgress('Deterministic Progress', 'Detail', 10, lldb.SBDebugger)
for i in range(3):
deterministic_progress2.Increment(1, f'Update {i}')
# Cause the progress end event to be sent even if we didn't increment the right
# number of times. Real world examples would be in a try-finally block to ensure
# progress clean-up.
deterministic_progress2.Finalize()
If you don't call Finalize() when the progress is not done, the progress object will eventually get
garbage collected by the Python runtime, the end event will eventually get sent, but it is best not to
rely on the garbage collection when using lldb.SBProgress.
Non-deterministic progresses behave the same, but omit the total in the constructor.
non_deterministic_progress = lldb.SBProgress('Non deterministic progress, 'Detail', lldb.SBDebugger)
for i in range(10):
non_deterministic_progress.Increment(1)
# Explicitly send a progressEnd, otherwise this will be sent
# when the python runtime cleans up this object.
non_deterministic_progress.Finalize()
") lldb::SBProgress;
%feature("docstring",
"Finalize the SBProgress, which will cause a progress end event to be emitted. This