[LLDB-DAP] Send Progress update message over DAP (#123837)

When testing my SBProgress DAP PR (#123826), I noticed Progress update
messages aren't sent over DAP. This patch adds the lldb progress ev

[LLDB-DAP] Send Progress update message over DAP (#123837)

When testing my SBProgress DAP PR (#123826), I noticed Progress update
messages aren't sent over DAP. This patch adds the lldb progress event's
message to the body when sent over DAP.

Before



Now


Tested with my [progress tester
command](https://gist.github.com/Jlalond/48d85e75a91f7a137e3142e6a13d0947),
testing 10 events 5 seconds apart 1-10

show more ...

[lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in ProgressEvent.cpp; addressing #108745 (#114087)

I hope it was missed unintentionally, pushing the same for the review.
Ref: https:/

[lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in ProgressEvent.cpp; addressing #108745 (#114087)

I hope it was missed unintentionally, pushing the same for the review.
Ref: https://github.com/llvm/llvm-project/pull/108745

---------

Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>

show more ...

[lldb-vscode] Use a switch to avoid else-after-return (NFC)

Use a switch to avoid else-after-return.

Differential revision: https://reviews.llvm.org/D158788

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/

Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/

show more ...

[vscode] fix ubsan problem in the progress event reporter

The error

UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/tools/l

[vscode] fix ubsan problem in the progress event reporter

The error

UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/tools/lldb-vscode/ProgressEvent.cpp:89:64 in

was found in https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/1910/consoleFull#-15641370498254eaf0-7326-4999-85b0-388101f2d404

It turns out that we were not setting m_event_type when initializatin
and update case. The fix is very simple.

Differential Revision: https://reviews.llvm.org/D105832

show more ...

Retry of [lldb-vscode] only report long running progress events

This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/

Retry of [lldb-vscode] only report long running progress events

This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/stdio

Differential Revision: https://reviews.llvm.org/D101128

show more ...

Revert "[lldb-vscode] only report long running progress events"

This reverts commit 610d474cfd82f11dc4702e2cf1b2485584d7c243.

lldb-vscode is crashing.

[lldb-vscode] only report long running progress events

When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it

[lldb-vscode] only report long running progress events

When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128

show more ...

Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"

This reverts commit f2c009dbcfd11fd1e8941513dcf49fffe43565a1.
This reverts commit aa46

Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"

This reverts commit f2c009dbcfd11fd1e8941513dcf49fffe43565a1.
This reverts commit aa4685c0fb3aab5acb90be5fd3eb5ba8bf1e3211.

show more ...

[lldb-vscode] only report long running progress events

When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it

[lldb-vscode] only report long running progress events

When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128

show more ...

[lldb-vscode] Reduce chattiness of progress events

Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 2000

[lldb-vscode] Reduce chattiness of progress events

Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 20000 events fired. Sending all these events to the IDE can break it. For example, debugging a huge binary resulted in around 50 million messages, which rendered the IDE useless, as it was spending all of its resources simply parsing messages and updating the UI.

A way to fix this is to send unique percentage updates, which are at most 100 per job, which is not much. I was able to debug that big target and confirm that only unique percentage notifications are sent. I can't write a test for this because the current test is flaky. I'll figure out later how to make the test reliable, but fixing this will unblock us from deploy a new version of lldb-vscode.

Differential Revision: https://reviews.llvm.org/D100443

show more ...