| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
llvm::ArrayRef
Differential Revision: https://reviews.llvm.org/D49017
llvm-svn: 343130
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:
Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.
Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.
This patch narrows the contract the CompletionRequest has with the different handlers to:
1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.
Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.
Otherwise this patch just completely hides the internal StringList to the different handlers.
The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.
Reviewers: jingham, davide, labath
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49322
llvm-svn: 338151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single CompletionRequest. In some cases we also pass an option
vector/index, but as we don't always have this information, it currently is not part of the
CompletionRequest class.
The constructor of the CompletionRequest is now also more sensible. You only pass the
user input, cursor position and your list of matches to the request and the rest will be
inferred (using the same code we used before to calculate this). You also have to pass these
match window parameters to it, even though they are unused right now.
The patch shouldn't change any behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48976
llvm-svn: 337031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
|
| |
|
|
| |
llvm-svn: 298412
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26721
llvm-svn: 287188
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
|
| |
|
|
| |
llvm-svn: 283603
|
| |
|
|
| |
llvm-svn: 283494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7676
llvm-svn: 230005
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Patch by Robert Matusewicz
llvm-svn: 206711
|
| |
|
|
|
|
|
|
| |
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to:
(lldb) b main
Breakpoint created: 1: name = 'main', locations = 1
Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to:
(lldb) settings set interpreter.expand-regex-aliases true
(lldb) b main
breakpoint set --name 'main'
Breakpoint created: 1: name = 'main', locations = 1
Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean).
Fixed auto completion for settings names when nothing has been type (it should show all settings).
llvm-svn: 162418
|
|
|
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
|
