Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke

Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke the build on Windows, see comments on https://reviews.llvm.org/D130309

It also reverts these follow-ups:

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14.

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24.

Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe877248b85b34878e75d5510339325ee087d0.

show more ...

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const ref

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

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

show more ...

[lldb/Core] Fix finite progress event reporting

This patch should fix event handling for finite progress reports.

Previously, the event handler would get stuck when receiving a finite
progress repo

[lldb/Core] Fix finite progress event reporting

This patch should fix event handling for finite progress reports.

Previously, the event handler would get stuck when receiving a finite
progress report, and stop displaying upcoming reports.
This was due to the fact that we were checking if the progress event was
completed by calling `GetCompleted` but returns the completion amount
instead of saying whether it's completed.

That caused the current event id to remain the same, preventing all the
following progress reports to be shown to the user.

This patch also adds some logging to facilitate debugging progress events.

rdar://91788326

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

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb] Add support for specifying a log handler

This patch adds a new flag to `log enable`, allowing the user to specify
a custom log handler. In addition to the default (stream) handler, this
allow

[lldb] Add support for specifying a log handler

This patch adds a new flag to `log enable`, allowing the user to specify
a custom log handler. In addition to the default (stream) handler, this
allows using the circular log handler (which logs to a fixed size,
in-memory circular buffer) as well as the system log handler (which logs
to the operating system log).

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

show more ...

[lldb] Make thread safety the responsibility of the log handlers

Drop the thread-safe flag and make the locking strategy the
responsibility of the individual log handler.

Previously we got away wit

[lldb] Make thread safety the responsibility of the log handlers

Drop the thread-safe flag and make the locking strategy the
responsibility of the individual log handler.

Previously we got away with a non-thread safe mode because we were using
unbuffered streams that rely on the underlying syscalls/OS for
synchronization. With the introduction of log handlers, we can have
arbitrary logic involved in writing out the logs. With this patch the
log handlers can pick the most appropriate locking strategy for their
particular implementation.

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

show more ...

[lldb] Support a buffered logging mode

This patch adds a buffered logging mode to lldb. A buffer size can be
passed to `log enable` with the -b flag. If no buffer size is specified,
logging is unbuf

[lldb] Support a buffered logging mode

This patch adds a buffered logging mode to lldb. A buffer size can be
passed to `log enable` with the -b flag. If no buffer size is specified,
logging is unbuffered.

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

show more ...

Don't use Optional::hasValue (NFC)

[lldb] Remove LogHandler::Create functions (NFC)

Remove the LogHandler::Create functions. Except for the StreamHandler
they were just forwarding their arguments to std::make_shared.

[lldb] Introduce the concept of a log handler (NFC)

This patch introduces the concept of a log handlers. Log handlers allow
customizing the way log output is emitted. The StreamCallback class
tried

[lldb] Introduce the concept of a log handler (NFC)

This patch introduces the concept of a log handlers. Log handlers allow
customizing the way log output is emitted. The StreamCallback class
tried to do something conceptually similar. The benefit of the log
handler interface is that you don't need to conform to llvm's
raw_ostream interface.

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

show more ...

[lldb/Core] Fix "sticky" long progress messages

When the terminal window is too small, lldb would wrap progress messages
accross multiple lines which would break the progress event handling
code tha

[lldb/Core] Fix "sticky" long progress messages

When the terminal window is too small, lldb would wrap progress messages
accross multiple lines which would break the progress event handling
code that is supposed to clear the message once the progress is completed.

This causes the progress message to remain on the screen, sometimes partially,
which can be confusing for the user.

To fix this issue, this patch trims the progress message to the terminal
width taking into account the progress counter leading the message for
finite progress events and also the trailing `...`.

rdar://91993836

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

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb] use one shared ThreadPool and task groups

As a preparation for parallelizing loading of symbols (D122975),
it is necessary to use just one thread pool to avoid using
a thread pool from inside

[lldb] use one shared ThreadPool and task groups

As a preparation for parallelizing loading of symbols (D122975),
it is necessary to use just one thread pool to avoid using
a thread pool from inside a task of another thread pool.

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

show more ...

[lldb] Session transcript should use the async debugger streams

When writing out the session transcript, print output to the
asynchronous debugger stream to prevent it from potentially interleaving

[lldb] Session transcript should use the async debugger streams

When writing out the session transcript, print output to the
asynchronous debugger stream to prevent it from potentially interleaving
with other output.

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

show more ...

[lldb] Print diagnostic prefixes (error, warning) in color

Print diagnostic prefixes (error, warning) in their respective colors
when colors are enabled.

[lldb] Don't report progress in the REPL

Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you'

[lldb] Don't report progress in the REPL

Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you're waiting for the next line to be executed in the REPL.

This patch disables reporting of progress events when in REPL mode.

rdar://91502950

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

show more ...

[lldb] Silence GCC/glibc warnings about ignoring the return value of write(). NFC.

This matches how another similar warning is silenced in
Host/posix/ProcessLauncherPosixFork.cpp.

Differential Revi

[lldb] Silence GCC/glibc warnings about ignoring the return value of write(). NFC.

This matches how another similar warning is silenced in
Host/posix/ProcessLauncherPosixFork.cpp.

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

show more ...

[lldb] Report debugger diagnostics as events

Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report

[lldb] Report debugger diagnostics as events

Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.

The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.

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

show more ...

[lldb] Use the debugger's asynchronous output stream for progress events.

Use the debugger's asynchronous output stream for printing progress
events. This allows the active IOHandler to be in charge

[lldb] Use the debugger's asynchronous output stream for progress events.

Use the debugger's asynchronous output stream for printing progress
events. This allows the active IOHandler to be in charge of printing
them and doing the necessary synchronization.

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

show more ...

[lldb] Use the IOHandler's stream instead of the debugger's in PrintAsync

PrintAsync is relying on the IOHandler to print to the output/error
stream. In that context it doesn't make much sense that

[lldb] Use the IOHandler's stream instead of the debugger's in PrintAsync

PrintAsync is relying on the IOHandler to print to the output/error
stream. In that context it doesn't make much sense that this is using
the debugger's streams rather than the one from the IOHandler.

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

show more ...

[lldb] Move ProgressEventData out of debugger and into its own file (NFC)

Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data

[lldb] Move ProgressEventData out of debugger and into its own file (NFC)

Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data for diagnostics.

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

show more ...

[lldb] Always listen for progress events in the default event handler

We came to the conclusion that this doesn't matter for VSCode/Xcode
because they don't use the default event loop and that other

[lldb] Always listen for progress events in the default event handler

We came to the conclusion that this doesn't matter for VSCode/Xcode
because they don't use the default event loop and that other clients
who might care should use the setting.

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

show more ...

[lldb] Fix -Wformat warning after 5a27b99825a5ba3a7a2eec3d35aea381a3ba9a31

No functional changes intended.

[lldb] A few small changes to HandleProgressEvent

Of course I only noticed these things *after* landing the original
patch...

- Flush the output after clearing the line.
- Move up the printing th

[lldb] A few small changes to HandleProgressEvent

Of course I only noticed these things *after* landing the original
patch...

- Flush the output after clearing the line.
- Move up the printing the carriage return to avoid duplication.
- Use hexadecimal instead of octal for escape codes.

show more ...

[lldb] Always move the cursor back after printing progress

This got lost while iterating on the patch. We need to always move the
cursor to the front of the line so that if something else
(asynchron

[lldb] Always move the cursor back after printing progress

This got lost while iterating on the patch. We need to always move the
cursor to the front of the line so that if something else
(asynchronously) prints to the debugger's output it overwrites the
progress message.

show more ...

[lldb] Add a setting to change the progress color

Add a setting to change how progress is shown in a color enabled
terminal. This follows the existing -prefix, -suffix pattern
that's used elsewhere

[lldb] Add a setting to change the progress color

Add a setting to change how progress is shown in a color enabled
terminal. This follows the existing -prefix, -suffix pattern
that's used elsewhere in lldb.

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

show more ...

[lldb] Show progress events in the command line driver

This patch adds support for showing progress events when using lldb on
the command line. It spawns a separate thread that listens for progress

[lldb] Show progress events in the command line driver

This patch adds support for showing progress events when using lldb on
the command line. It spawns a separate thread that listens for progress
events and prints them to the debugger's output stream.

It's nothing fancy (yet), for now it just prints the progress message.
If we know the total number of items being processed, we prefix the
message with something like [1/100], similar to ninja's output.

This patch doesn't use any fancy terminal manipulation: it uses a simple
carriage return (\r) to bring the cursor to the front of the line and
vt100 escape codes to clear the (rest) of the line.

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

show more ...