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] 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] Check if language is supported before creating a REPL instance

Currently, we'll try to instantiate a ClangREPL for every known
language. The plugin manager already knows what languages it sup

[lldb] Check if language is supported before creating a REPL instance

Currently, we'll try to instantiate a ClangREPL for every known
language. The plugin manager already knows what languages it supports,
so rely on that to only instantiate a REPL when we know the requested
language is supported.

rdar://86439474

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

show more ...

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.

In order to future-proof the code for the GDB variant:

1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.

2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.

3. Use the intersection of all three flags when matching against
the three possible values.

This commit does not change the actual bits used by LLDB.

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

show more ...

Use zu rather than llu format specifier for size_t (-Wformat warning fix).

Add '<' meta command to read in code from external file

Perform all error handling in ReadCode()

Add :help text describing “< path”, add extra line before Commands

Differential Revision: https://r

Add '<' meta command to read in code from external file

Perform all error handling in ReadCode()

Add :help text describing “< path”, add extra line before Commands

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

show more ...

[lldb] Fix missing characters when autocompleting LLDB commands in REPL

Summary:

When tabbing to complete LLDB commands in REPL, characters would at best be
missing but at worst cause the REPL to c

[lldb] Fix missing characters when autocompleting LLDB commands in REPL

Summary:

When tabbing to complete LLDB commands in REPL, characters would at best be
missing but at worst cause the REPL to crash due to out of range string access.
This patch appends the command character to the completion results to fulfill
the assumption that all matches are prefixed by the request's cursor argument
prefix.

Bug report for the Swift REPL
https://bugs.swift.org/browse/SR-12867

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[lldb/Interpreter] Support color in CommandReturnObject

Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabl

[lldb/Interpreter] Support color in CommandReturnObject

Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.

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

show more ...

[lldb/REPL] Fix unhandled switch case

Fix warning: enumeration value 'eExpressionThreadVanished' not handled
in switch [-Wswitch]

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string l

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.

show more ...

[lldb][NFCI] Remove UserExpression::GetJITModule

UserExpression::GetJITModule was used to support an option in
UserExpression::Evaluate that let you hold onto the JIT Module used during
the expressi

[lldb][NFCI] Remove UserExpression::GetJITModule

UserExpression::GetJITModule was used to support an option in
UserExpression::Evaluate that let you hold onto the JIT Module used during
the expression evaluation. This was only actually used in one spot --
REPL::IOHandlerInputComplete. That method didn't actually take use the
JIT module it got back, so this feature was not used in practice.
This means that we can delete the support in UserExpression::Evaluate
and delete the UserExpression::GetJITModule method entirely.

show more ...

[lldb] Use CompletionRequest in REPL::CompleteCode and remove translation code to old API

Any REPL client should just move to CompletionRequest instead of relying on
the translation code from the ol

[lldb] Use CompletionRequest in REPL::CompleteCode and remove translation code to old API

Any REPL client should just move to CompletionRequest instead of relying on
the translation code from the old API, so let's remove that translation code.

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb/Debugger] Rename IO handler methods to be more meaningful (NFC)

Make it clear form the method names whether they are synchronous or
asynchronous.

Add missing nullptr checks.

GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.

Inspired by rdar:

Add missing nullptr checks.

GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.

Inspired by rdar://problem/58317195

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

show more ...

remove a smattering of isolated, unnecessary uses of FILE*

Summary:
There a a few call sites that use FILE* which are easy to
fix without disrupting anything else.

Reviewers: JDevlieghere, jasonmol

remove a smattering of isolated, unnecessary uses of FILE*

Summary:
There a a few call sites that use FILE* which are easy to
fix without disrupting anything else.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: JDevlieghere, labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 374239

show more ...

remove File::SetStream(), make new files instead.

Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of cal

remove File::SetStream(), make new files instead.

Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.

My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.

In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)

However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)

In order for SBFile to use shared_ptr<File>, everything else should
as well.

If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.

Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 373090

show more ...

Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm

Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);

This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 373003

show more ...

[lldb][NFC] Remove CompletionRequest::GetCursorArgument and GetRawLineUntilCursor

They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added

[lldb][NFC] Remove CompletionRequest::GetCursorArgument and GetRawLineUntilCursor

They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added because the old API allowed to look
(in theory) behind the cursor position which is no longer possible.

llvm-svn: 372861

show more ...

[lldb][NFC] Remove Args::StripSpaces

This just reimplemented llvm::StringRef::[r/l]trim().

llvm-svn: 371181

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Summary:
We still have some leftovers of the old completion API in the inte

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.

Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 369624

show more ...

[lldb][NFC] Refactor remaining completion logic to use CompletionRequests

This patch moves the remaining completion functions from the
old completion API (that used several variables) to just
passin

[lldb][NFC] Refactor remaining completion logic to use CompletionRequests

This patch moves the remaining completion functions from the
old completion API (that used several variables) to just
passing a single CompletionRequest.

This is for the most part a simple change as we just replace
the old arguments with a single CompletionRequest argument.

There are a few places where I had to create new CompletionRequests
in the called functions as CompletionRequests itself are immutable
and don't expose their internal match list anymore. This means that
if a function wanted to change the CompletionRequest or directly
access the result list, we need to work around this by creating
a new CompletionRequest and a temporary match/description list.

Preparation work for rdar://53769355

llvm-svn: 369000

show more ...

[CompletionRequest] Remove unimplemented members.

Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay,

[CompletionRequest] Remove unimplemented members.

Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.

llvm-svn: 367385

show more ...

Quiet command regex instructions during batch execution

Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninent

Quiet command regex instructions during batch execution

Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.

For example:

command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...

I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.

However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.

Reviewers: clayborg, jingham

Reviewed By: clayborg

Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits

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

llvm-svn: 355793

show more ...