[lldb][ConstString] Prevent GetString from constructing a std::string with a nullptr (#95175)

This patch prevents passing a `nullptr` to the `std::string` constructor
in `GetString`. This prevents

[lldb][ConstString] Prevent GetString from constructing a std::string with a nullptr (#95175)

This patch prevents passing a `nullptr` to the `std::string` constructor
in `GetString`. This prevents UB arising from calling `GetString` on a
default-constructed `ConstString`.

show more ...

[lldb] Streamline ConstString -> std::string conversion (NFC) (#79649)

Make it easier to go from a ConstString to a std::string without having
to go through a C-String or a llvm::StringRef. I made

[lldb] Streamline ConstString -> std::string conversion (NFC) (#79649)

Make it easier to go from a ConstString to a std::string without having
to go through a C-String or a llvm::StringRef. I made the conversion
operator explicit as this is a relatively expensive operations (compared
to a StringRef or string_view).

show more ...

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outli

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

show more ...

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be seriali

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.

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

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 ...

Allow direct comparison of ConstString against StringRef

Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn

Allow direct comparison of ConstString against StringRef

Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn the other string into a ConstString. This makes sense as
comparing ConstStrings against each other is only a fast pointer comparison.

However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when
we just want to compare a given ConstString against a hardcoded value, for example like this:
```
if (extension != ConstString(".oat") && extension != ConstString(".odex"))
```

Obviously this kind of defeats the point of ConstStrings. In the comparison above we would
construct two temporary ConstStrings every time we hit the given code. Constructing a
ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly
an exclusive write-lock and then look up our temporary string in the string map of the pool.
So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.

I initially wanted to just fix these issues by turning the temporary ConstString in static variables/
members, but that made the code much less readable. Instead I propose to add a new overload
for the ConstString comparison operator that takes a StringRef. This comparison operator directly
compares the ConstString content against the given StringRef without turning the StringRef into
a ConstString.

This means that the example above can look like this now:
```
if (extension != ".oat" && extension != ".odex")
```
It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing
the temporary ConstString instances. Instead this should end up just being a direct string comparison
of the two given strings on most compilers.

This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new
comparison operator. It also adds a some unit tests for the new and old comparison operator.

Reviewers: #lldb, JDevlieghere, espindola, amccarth

Reviewed By: JDevlieghere, amccarth

Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits

Tags: #lldb

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

llvm-svn: 359281

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Fix: ConstString::GetConstCStringAndSetMangledCounterPart() should update the value if the key exists already

Summary:
This issue came up because it caused problems in our unit tests. The StringPool

Fix: ConstString::GetConstCStringAndSetMangledCounterPart() should update the value if the key exists already

Summary:
This issue came up because it caused problems in our unit tests. The StringPool did connect counterparts only once and silently ignored the values passed in subsequent calls.
The simplest solution for the unit tests would be silent overwrite. In practice, however, it seems useful to assert that we never overwrite a different mangled counterpart.
If we ever have mangled counterparts for other languages than C++, this makes it more likely to notice collisions.

I added an assertion that allows the following cases:
* inserting a new value
* overwriting the empty string
* overwriting with an identical value

I fixed the unit tests, which used "random" strings and thus produced collisions.
It would be even better if there was a way to reset or isolate the StringPool, but that's a different story.

Reviewers: jingham, friss, labath

Subscribers: lldb-commits

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

llvm-svn: 339669

show more ...

Add ConstString test FromMidOfBufferStringRef

Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism

Add ConstString test FromMidOfBufferStringRef

Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism. From this test it seems to be fine. Maybe useful to keep?

Reviewers: labath

Subscribers: lldb-commits

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

llvm-svn: 339292

show more ...

Add ConstString::IsNull() to tell between null vs. empty strings and fix usage in Mangled::GetDemangledName()

Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangl

Add ConstString::IsNull() to tell between null vs. empty strings and fix usage in Mangled::GetDemangledName()

Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangled::GetDemangledName() was incorrect. What it actually wants is a check for null-string. Split this off of D50071 and added a test to clarify usage.

Reviewers: labath, jingham

Subscribers: erik.pilkington, lldb-commits

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

llvm-svn: 339014

show more ...

Change ConstString::SetCStringWithMangledCounterpart to use StringRef

This should simplify the upcoming demangling patch (D50071). While I was
in there, I also added a quick test for the function.

Change ConstString::SetCStringWithMangledCounterpart to use StringRef

This should simplify the upcoming demangling patch (D50071). While I was
in there, I also added a quick test for the function.

llvm-svn: 338995

show more ...

Remove LIBLLDB_LOG_VERBOSE category

Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the firs

Remove LIBLLDB_LOG_VERBOSE category

Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.

I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).

Reviewers: jingham, zturner

Subscribers: lldb-commits

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

llvm-svn: 294113

show more ...