10 Commits

Author SHA1 Message Date
Alex Langford
2014572d9a [lldb][NFCI] Remove unneeded ConstString constructions for OptionValueProperties::AppendProperty
I removed ConstString from OptionValueProperties in 643ba926c1f6, but
there are a few call sites that still create a ConstString as an
argument. I did not catch these initially because ConstString has an
implicit conversion method to StringRef.

Differential Revision: https://reviews.llvm.org/D153673
2023-06-26 11:06:29 -07:00
Jonas Devlieghere
3ebb33632a
[lldb] Complete OptionValue cleanup (NFC)
Make the `Get.*Value` and `Set.*Value` function private and migrate the
last remaining call sites to the new overloaded/templated functions.
2023-05-14 20:18:47 -07:00
Jonas Devlieghere
611bd6c6ae
[lldb] Make exe_ctx an optional argument in OptionValueProperties (NFC)
The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.
2023-05-02 10:36:11 -07:00
Jonas Devlieghere
ddd9358bca
[lldb] Remove unused will_modify argument (NFC)
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
2023-05-02 00:20:34 -07:00
Alex Langford
e53e1de57e [lldb] Change ObjectValueDictionary to use a StringMap
llvm has a structure for maps where the key's type is a string. Using
that also means that the keys for OptionValueDictionary don't stick
around forever in ConstString's StringPool (even after they are gone).

The only thing we lose here is ordering: iterating over the map where the keys
are ConstStrings guarantees that we iterate in alphabetical order.
StringMap makes no guarantees about the ordering when you iterate over
the entire map.

Differential Revision: https://reviews.llvm.org/D149482
2023-05-01 16:17:24 -07:00
Alex Langford
96a800c07f [lldb] Change setting descriptions to use StringRef instead of ConstString
These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.

Differential Revision: https://reviews.llvm.org/D148679
2023-04-19 14:45:02 -07:00
Shafik Yaghmour
fd14646043 [LLDB] Applying clang-tidy modernize-use-override over LLDB
Applied clang-tidy modernize-use-override over LLDB and added it to the LLDB .clang-tidy config.

Differential Revision: https://reviews.llvm.org/D123340
2022-04-22 13:29:47 -07:00
David Blaikie
776be16ba0 Fix virtual-dtor warning a different way, since a virtual dtor is not required for this use case. 2021-03-01 09:25:26 -08:00
Benjamin Kramer
99c24f7aa8 [lldb/Interpreter] Pacify -Wnon-virtual-dtor 2021-03-01 11:20:14 +01:00
Tatyana Krasnukha
f0f183ee4a [lldb/Interpreter] Fix deep copying for OptionValue classes
Some implementations of the DeepCopy function called the copy constructor that copied m_parent member instead of setting a new parent. Others just leaved the base class's members (m_parent, m_callback, m_was_set) empty.
One more problem is that not all classes override this function, e.g. OptionValueArgs::DeepCopy produces OptionValueArray instance, and Target[Process/Thread]ValueProperty::DeepCopy produces OptionValueProperty. This makes downcasting via static_cast invalid.

The patch implements idiom "virtual constructor" to fix these issues.
Add a test that checks DeepCopy for correct copying/setting all data members of the base class.

Differential Revision: https://reviews.llvm.org/D96952
2021-02-28 19:23:25 +03:00