summaryrefslogtreecommitdiff
path: root/lldb/source/Interpreter/Options.cpp
AgeCommit message (Collapse)Author
2025-05-13[lldb] Use std:::string::find with std::string_view (NFC) (#139679)Kazu Hirata
std::string::find accepts anything that can be converted to std::string_view starting in C++17. Since StringRef can be converted to std::string_view, we do not need to create a temporary instance of std::string here.
2025-01-31[lldb] Use llvm::Error instead of CommandReturnObject for error reporting ↵Jonas Devlieghere
(#125125) Use `llvm::Error` instead of `CommandReturnObject` for error reporting. The command return objects were populated with errors but never displayed. With this patch they're at least logged.
2024-10-20[lldb] Avoid repeated map lookups (NFC) (#113073)Kazu Hirata
2024-10-11Support inline diagnostics in CommandReturnObject (#110901)Adrian Prantl
and implement them for dwim-print (a.k.a. `p`) as an example. The next step will be to expose them as structured data in SBCommandReturnObject.
2024-09-24Add the ability to define custom completers to the parsed_cmd template. ↵jimingham
(#109062) If your arguments or option values are of a type that naturally uses one of our common completion mechanisms, you will get completion for free. But if you have your own custom values or if you want to do fancy things like have `break set -s foo.dylib -n ba<TAB>` only complete on symbols in foo.dylib, you can use this new mechanism to achieve that.
2024-09-16[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)Youngsuk Kim
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly ( 65b13610a5226b84889b923bae884ba395ad084d for further reference ) * Don't call raw_string_ostream::flush(), which is essentially a no-op. * Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
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.
2024-06-17[LLDB] Remove dead code (NFC) (#95713)Shivam Gupta
The dead code is caught by PVS studio analyzer - https://pvs-studio.com/en/blog/posts/cpp/1126/, fragment N12. Warning message - V523 The 'then' statement is equivalent to the 'else' statement. Options.cpp 1212
2024-05-23Add a createError variant without error code (NFC) (#93209)Adrian Prantl
For the significant amount of call sites that want to create an incontrovertible error, such a wrapper function creates a significant readability improvement and lowers the cost of entry to add error handling in more places.
2024-02-21[lldb] Standardize command option parsing error messages (#82273)Alex Langford
I have been looking to simplify parsing logic and improve the interfaces so that they are both easier to use and harder to abuse. To be specific, I am referring to functions such as `OptionArgParser::ToBoolean`: I would like to go from its current interface to something more like `llvm::Error<bool> ToBoolean(llvm::StringRef option_arg)`. Through working on that, I encountered 2 inconveniences: 1. Option parsing code is not uniform. Every function writes a slightly different error message, so incorporating an error message from the `ToBoolean` implementation is going to be laborious as I figure out what exactly needs to change or stay the same. 2. Changing the interface of `ToBoolean` would require a global atomic change across all of the Command code. This would be quite frustrating to do because of the non-uniformity of our existing code. To address these frustrations, I think it would be easiest to first standardize the error reporting mechanism when parsing options in commands. I do so by introducing `CreateOptionParsingError` which will create an error message of the shape: Invalid value ('${option_arg}') for -${short_value} ('${long_value}'): ${additional_context} Concretely, it would look something like this: (lldb) breakpoint set -n main -G yay error: Invalid value ('yay') for -G (auto-continue): Failed to parse as boolean After this, updating the interfaces for parsing the values themselves should become simpler. Because this can be adopted incrementally, this should be able to done over the course of time instead of all at once as a giant difficult-to-review change. I've changed exactly one function where this function would be used as an illustration of what I am proposing.
2023-12-16[lldb] Use StringRef::{starts,ends}_with (NFC)Kazu Hirata
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-06-06[lldb/Commands] Add support to auto-completion for user commandsMed Ismail Bennani
This patch should allow the user to set specific auto-completion type for their custom commands. To do so, we had to hoist the `CompletionType` enum so the user can access it and add a new completion type flag to the CommandScriptAdd Command Object. So now, the user can specify which completion type will be used with their custom command, when they register it. This also makes the `crashlog` custom commands use disk-file completion type, to browse through the user file system and load the report. Differential Revision: https://reviews.llvm.org/D152011 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-02-17[lldb] Add expression command options in dwim-printDave Lee
Adopt `expression`'s options in `dwim-print`. This is primarily added to support the `--language`/`-l` flag. Differential Revision: https://reviews.llvm.org/D144114
2023-01-03[lldb] Remove spurious `n` at the end of option error messageJonas Devlieghere
When migrating to `ReportError` the newline (`\n`) at the end of the error message was meant to be removed, but instead only the backslash got deleted.
2022-09-14Revert "Revert "Be more careful to maintain quoting information when parsing ↵Jim Ingham
commands."" This reverts commit ac05bc0524c66c74278b26742896a4c634c034cf. I had incorrectly removed one set of checks in the option handling in Options::ParseAlias because I couldn't see what it is for. It was a bit obscure, but it handled the case where you pass "-something=other --" as the input_line, which caused the built-in "run" alias not to return the right value for IsDashDashCommand, causing TestHelp.py to fail.
2022-09-13Revert "Be more careful to maintain quoting information when parsing commands."Jim Ingham
This reverts commit 6c089b2af5d8d98f66b27b67f70958f520820a76. This was causing the test test_help_run_hides_options from TestHelp.py to fail on Linux and Windows (but the test succeeds on macOS). The decision to print option information is determined by CommandObjectAlias::IsDashDashCommand which was changed, but only by replacing an inline string constant with a const char * CommandInterpreter::g_argument which has the same string value. I can't see why this would fail, I'll have to spin up a vm to see if I can repo there.
2022-09-13Be more careful to maintain quoting information when parsing commands.Jim Ingham
This is particularly a problem for alias construction, where you might want to have a backtick surrounded option in the alias. Before this patch: command alias expression -Z \`argc\` -- argv for instance would be rendered as: expression -Z argc -- argv and would fail to work. Differential Revision: https://reviews.llvm.org/D133045
2022-08-08[lldb] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song
2022-06-24[lldb] Replace Host::SystemLog with Debugger::Report{Error,Warning}Jonas Devlieghere
As it exists today, Host::SystemLog is used exclusively for error reporting. With the introduction of diagnostic events, we have a better way of reporting those. Instead of printing directly to stderr, these messages now get printed to the debugger's error stream (when using the default event handler). Alternatively, if someone is listening for these events, they can decide how to display them, for example in the context of an IDE such as Xcode. This change also means we no longer write these messages to the system log on Darwin. As far as I know, nobody is relying on this, but I think this is something we could add to the diagnostic event mechanism. Differential revision: https://reviews.llvm.org/D128480
2022-05-16[lldb][NFC] Simplify GenerateOptionUsageDavid Spickett
Once we get into the if block we know the value of only_print_args. Move some variables closer to point of use. Depends on D125218 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D125219
2022-05-16[lldb][NFC] Make cmd a reference in GenerateOptionUsageDavid Spickett
Nowhere in lldb do we call this with a null pointer. If we did, the first line of the function would fault anyway. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D125218
2022-05-03[lldb][NFC] Refactor printing of short options in helpDavid Spickett
Instead of building a set twice for optional and required, build a set for each while walking the options once. Then take advantage of set being sorted meaning we don't have to enforce the upper/lower order ourselves. Just cleaned up the formatting on the later loops. Combined the if conditions and used a single line if. Depends on D123501 Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D123502
2022-05-03[lldb][NFC] Simplify part of Options::GenerateOptionUsageDavid Spickett
Use llvm::enumerate, remove an unused arg name stream and replace repeated uses of indexing to get the option def. We could use map instead of multimap but I'm not 100% that would be NFC. All short options should be unique in theory. Depends on D123500 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D123501
2022-01-12[lldb] Don't print "Command Options Usage:" for an alias with no optionsDavid Spickett
"shell" is an alias to "platform shell -h --". Previously you would get this help text: (lldb) help shell Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.) Syntax: shell <shell-command> Command Options Usage: 'shell' is an abbreviation for 'platform shell -h --' Since the code doesn't handle the base command having options but the alias removing them. With these changes you get: (lldb) help shell Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.) Syntax: shell <shell-command> 'shell' is an abbreviation for 'platform shell -h --' Note that we already handle a non-alias command having no options, for example "quit": (lldb) help quit Quit the LLDB debugger. Syntax: quit [exit-code] Reviewed By: JDevlieghere, jingham Differential Revision: https://reviews.llvm.org/D117004
2021-06-17[lldb] Remove redundant calls to set eReturnStatusFailedDavid Spickett
Since https://reviews.llvm.org/D103701 AppendError<...> sets this for you. This change includes all of the non-command uses. Some uses remain where it's either tricky to reason about the logic, or they aren't paired with AppendError calls. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D104379
2021-02-28[lldb/Interpreter][NFC] Remove explicit default initialization of members ↵Tatyana Krasnukha
and base classes According to clang-tidy's readability-redundant-member-init.
2021-02-28[lldb/Interpreter][NFC] Replace default constructors/destructors bodies with ↵Tatyana Krasnukha
"=default"
2020-11-12[lldb][NFC] Move OptionDefinition from lldb-private-types.h to its own ↵Raphael Isemann
Utility header Also moves the curious isprint8 function (which was used to check whether we have a valid short option) into the struct and documents it.
2020-07-20[lldb] Remove redundant WithFormat suffixes (NFC)Jonas Devlieghere
Replace calls to FooWithFormat() with calls to Foo() when only one argument is provided and the given string doesn't need to be formatted.
2020-06-24[lldb] Use std::make_unique<> (NFC)Jonas Devlieghere
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-02-11[lldb][NFC] Remove ConstString -> const char * -> StringRef conversions when ↵Raphael Isemann
calling Stream::Indent Let's just pass in a StringRef and save the strlen call when rebuilding the StringRef parameter.
2020-02-06[LLDB] Fix compilation with GCC 5Martin Storsjö
Differential Revision: https://reviews.llvm.org/D74084
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-10-03Break out the Python class & key/value options into a separate OptionGroup.Jim Ingham
Use this in the scripted breakpoint command. Added some tests for parsing the key/value options. This uncovered a bug in handling parsing errors mid-line. I also fixed that bug. Differential Revision: https://reviews.llvm.org/D68363 llvm-svn: 373673
2019-09-25[lldb][NFC] Remove CompletionRequest::GetCursorArgument and ↵Raphael Isemann
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
2019-09-25[lldb][NFC] Remove useless cursor shifting in Options::HandleOptionCompletionRaphael Isemann
The cursor position is always at the end of the current argument (as the argument cut off after the cursor position). So this code is a no-op and can be removed. llvm-svn: 372851
2019-09-23[lldb][NFC] Remove unused variable in Options::HandleOptionArgumentCompletionRaphael Isemann
llvm-svn: 372574
2019-09-23[lldb][NFC] Remove dead code in Options::HandleOptionArgumentCompletionRaphael Isemann
llvm-svn: 372572
2019-09-23[lldb] Make cursor index in CompletionRequest unsignedRaphael Isemann
The fact that index==-1 means "no arguments" is not obvious and only used in one place from what I can tell. Also fixes several warnings about using the cursor index as if it was a size_t when comparing. Not fully NFC as we now also correctly update the partial argument list when injecting the fake empty argument in the CompletionRequest constructor. llvm-svn: 372566
2019-09-23[lldb][NFC] Remove argument prefix checking boilerplate when adding completionsRaphael Isemann
llvm-svn: 372561
2019-09-13[lldb][NFC] Remove ArgEntry::ref memberRaphael Isemann
The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13[lldb][NFC] Make ArgEntry::quote private and provide a getterRaphael Isemann
llvm-svn: 371823
2019-09-02[lldb] Add description to option completions.Raphael Isemann
Summary: Right now our argument completions are rather cryptic for command options as they only list the letters: ``` (lldb) breakpoint set - Available completions: -G -C -c -d -i -o -q -t -x [...] ``` With the new completion API we can easily extend this with the flag description so that it looks like this now: ``` (lldb) breakpoint set - Available completions: -G -- The breakpoint will auto-continue after running its commands. -C -- A command to run when the breakpoint is hit, can be provided more than once, the commands will get run in order left to right. -c -- The breakpoint stops only if this condition expression evaluates to true. -d -- Disable the breakpoint. -i -- Set the number of times this breakpoint is skipped before stopping. -o -- The breakpoint is deleted the first time it stop causes a stop. -q -- The breakpoint stops only for threads in the queue whose name is given by this argument. -t -- The breakpoint stops only for the thread whose TID matches this argument. -x -- The breakpoint stops only for the thread whose index matches this argument. ``` The same happens with --long-options now. Reviewers: #lldb, labath Reviewed By: labath Subscribers: labath, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67063 llvm-svn: 370628
2019-08-28[lldb] Fix and test completion for ambiguous long optionsRaphael Isemann
The refactoring patch for the option completion broke the completion for ambiguous long options. As this feature was also untested (as testing ambiguous options with the current test methods is impossible), I just noticed now. This patch restores the old behavior and adds a test for this feature. llvm-svn: 370185
2019-08-28[lldb][NFC] Get rid of C-strings in HandleOptionCompletionRaphael Isemann
llvm-svn: 370179
2019-08-22[lldb][NFC] Remove unused return value from HandleOptionArgumentCompletionRaphael Isemann
llvm-svn: 369635
2019-08-22[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann
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
2019-07-10Options: Reduce code duplicationPavel Labath
Summary: While investigating breakages caused by D63110, I noticed we were building the short options strings in three places. Some of them used a leading ':' to detect missing arguments, and some didn't. This was the indirect cause of D63110. Here, I move the common code into a utility function. Also, unify the code which appends the sentinel value at the end of the option vector, and make it harder for users to pass invalid argc-argv combos to getopt (another component of D63110) by having the OptionParser::Parse function take a (Mutable)ArrayRef. This unification has uncovered that we don't handle missing arguments while building aliases, However, it's not possible to write an effective test for this, as right now it is not possible to return an error out of the alias parsing code (which means we are printing the generic "failure" message even after this patch). Reviewers: mgorny, aprantl Reviewed By: mgorny Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D63770 llvm-svn: 365665
2019-06-25Options: Correctly check for missing argumentsPavel Labath
Relying on the value of optind for detecting missing arguments is unreliable because its value after a failed parse is an implementation detail. A more correct way to achieve this is to pass ':' at the beginning of option string, which tells getopt to return ':' for missing arguments. For this to work, I also had to add a nullptr at the end of the argv vector, as some getopt implementations did not work without that. This is also an implementation detail, as getopt should normally be called with argc+argc "as to main function" (i.e. null-terminated). Thanks to Michał Górny for testing this patch out on NetBSD. llvm-svn: 364317