summaryrefslogtreecommitdiff
path: root/lldb/source/Interpreter/OptionValueString.cpp
AgeCommit message (Collapse)Author
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl
This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ` ResultTy DoFoo(Status& error) ` to ` llvm::Expected<ResultTy> DoFoo() ` How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly ` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) ` plus the occasional manual cleanup.
2021-02-28[lldb/Interpreter] Fix deep copying for OptionValue classesTatyana Krasnukha
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
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-11Remove header grouping comments.Jonas Devlieghere
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
2018-04-17Move Args.cpp from Interpreter to UtilityPavel Labath
Summary: The Args class is used in plenty of places besides the command interpreter (e.g., anything requiring an argc+argv combo, such as when launching a process), so it needs to be in a lower layer. Now that the class has no external dependencies, it can be moved down to the Utility module. This removes the last (direct) dependency from the Host module to Interpreter, so I remove the Interpreter module from Host's dependency list. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D45480 llvm-svn: 330200
2017-05-12Rename Error -> Status.Zachary Turner
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-03-22Delete some more dead includes.Zachary Turner
This breaks the cycle between Target and PluginLanguageC++, reducing the overall cycle count from 43 to 42. llvm-svn: 298561
2017-02-02Move classes from Core -> Utility.Zachary Turner
This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2016-11-11Prevent at compile time converting from Error::success() to Expected<T>Mehdi Amini
This would trigger an assertion at runtime otherwise. Differential Revision: https://reviews.llvm.org/D26482 llvm-svn: 286562
2016-11-11Make the Error class constructor protectedMehdi Amini
This is forcing to use Error::success(), which is in a wide majority of cases a lot more readable. Differential Revision: https://reviews.llvm.org/D26481 llvm-svn: 286561
2016-09-23Update OptionGroup::SetValue to take StringRef.Zachary Turner
Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2015-05-22Fix use-after-free in OptionValueString.Zachary Turner
We were assigning a temporary std::string to a StringRef. Somehow this worked on every platform but Windows. llvm-svn: 238041
2015-02-20Refactor OptionValue::SetValueFromCString to use llvm::StringRefPavel Labath
Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7676 llvm-svn: 230005
2015-02-16Handle trailing spaces on "settings set" command more correctlyPavel Labath
Summary: Currently we have some settings which treat "\ " on settings set commands specially. E.g., it is a valid way of specifying an argument of " " to a target. However, this fails if "\ " is the last argument as CommandObjectSettingsSet strips trailing whitespace. This resulted in a surprising argument of "\" to the target. This patch disables the training whitespace removal at a global level. Instead, for each argument type we locally determine whether whitespace stripping makes sense. Currently, I strip whitespace for all simple object type except of regex and format-string, with the rationale that these two object types do their own complex parsing and we want to interfere with them as least as possible. Specifically, stripping the whitespace of a regex "\ " will result in a (surprising?) error "trailing backslash". Furthermore, the default value of dissasembly-format setting already contains a trailing space and there is no way for the user to type this in manually if we strip whitespace. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7592 llvm-svn: 229382
2015-01-13Fixed an issue where if the operating system python plug-in is changed at ↵Greg Clayton
runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2013-03-06Now that "settings set" will strip leading and trailing spaces, we need a ↵Greg Clayton
way to be able to specify string values that contain spaces. So now settings setting <property> <value>" can have a <value> that is quoted: settings set prompt "(lldb2) " llvm-svn: 176545
2012-12-11Adding a validation callback mechanism to OptionValueString (such a feature ↵Enrico Granata
might theoretically be added to the general OptionValue base class should the need arise) Using this mechanism, making sure that the options to pass a summary string or a named summary to frame variable do not have invalid values <rdar://problem/11576143> llvm-svn: 169927
2012-09-01Made it so changes to the prompt via "settings set prompt" get noticed by ↵Greg Clayton
the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
2012-08-22Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton
issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366