kubamracek updated this revision to Diff 152017.
kubamracek added a comment.
Fixing up test (it was using the "-t" flag).
Removing a leftover printf().
https://reviews.llvm.org/D44603
Files:
include/lldb/API/SBVariablesOptions.h
include/lldb/Interpreter/OptionGroupVariable.h
include/lldb/
aprantl added a comment.
Ok, then let's continue this way.
Comment at: tools/lldb-mi/MICmdBase.h:89
+ [] { return MIstatus::failure; },
+ const lldb::SBError error = lldb::SBError());
template T *GetOption(const CMIUtilString &vStrO
kubamracek updated this revision to Diff 152004.
kubamracek added a comment.
Switched on showing recognized args by default in "frame variable". Switched
"-t" to mean "omit" instead of "include".
Added documentation and an example into "help frame recognizer add" and into
python-reference.html.
jingham added a comment.
This code looks fine to me. The docs are a little thin.
You don't say how to make a recognizer anywhere except in the test example.
There should probably be an example in the long help for
CommandObjectFrameRecognizerAdd. Look for instance at the help for "breakpoint
kubamracek updated this revision to Diff 151991.
kubamracek added a comment.
Rebasing to current master.
https://reviews.llvm.org/D44603
Files:
include/lldb/API/SBVariablesOptions.h
include/lldb/Interpreter/OptionGroupVariable.h
include/lldb/Interpreter/ScriptInterpreter.h
include/lldb/
apolyakov added a comment.
> bool handleSBError(SBError error, std::function
> convert) {
> if (error.Success())
> return false;
>
> SetError(convert(error));
> return error_handler();
> }
>
> ...
> bool CMICmdCmdExecContinue::Execute() {
> if
> (handleSBError
teemperor created this revision.
This patch splits out functionality from the `Parse` method into different
methods.
This benefits the code completion work (which should reuse those methods) and
makes the
code a bit more readable.
Note that this patch is as minimal as possible. Some of the code
kubamracek updated this revision to Diff 151985.
kubamracek added a comment.
Cleaned up patch, clang-formatted, respects 80-columns now. Expanded test case.
Implemented all "frame recognizer" commands (add, delete, clear, list). Changed
iteration order on the list of active recognizers (so that
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335079: Correct the pathname that
PlatformDarwinKernel::ExamineKextForMatchingUUID (authored by jmolenda,
committed by ).
Changed prior to commit:
https://reviews.llvm.org/D48302?vs=151809&id=151981#to
Author: jmolenda
Date: Tue Jun 19 14:39:10 2018
New Revision: 335079
URL: http://llvm.org/viewvc/llvm-project?rev=335079&view=rev
Log:
Correct the pathname that PlatformDarwinKernel::ExamineKextForMatchingUUID
passes to the recursive search function so we only recursively
search the kext bundle di
labath added a comment.
How is this class different from `lldb_private::CleanUp`? Shouldn't we just
delete it and replace all uses with the pre-existing class?
Repository:
rL LLVM
https://reviews.llvm.org/D48337
___
lldb-commits mailing list
lld
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335078: Refactor OnExit utility class in ClangUserExpression
(authored by teemperor, committed by ).
Herald added a subscr
Author: teemperor
Date: Tue Jun 19 14:25:59 2018
New Revision: 335078
URL: http://llvm.org/viewvc/llvm-project?rev=335078&view=rev
Log:
Refactor OnExit utility class in ClangUserExpression
Summary:
OnExit ensures we call `ResetDeclMap` before this method ends. However,
we also have a few manual c
teemperor created this revision.
OnExit ensures we call `ResetDeclMap` before this method ends. However,
we also have a few manual calls to ResetDeclMap in there that are actually
unnecessary
because of this (calling the method multiple times has no effect). This patch
also moves
the class out o
aprantl added a comment.
I think I misread your patch. Now the naming of success_handler makes much more
sense, too.
What do you think about defining a function that takes an SBError result, and a
function that converts this error into a string? This would allow chaining more
than one SBAPI co
teemperor updated this revision to Diff 151967.
teemperor added a comment.
- Generalized test case a bit more and no longer checking only for 0.
https://reviews.llvm.org/D48303
Files:
packages/Python/lldbsuite/test/expression_command/xvalue/Makefile
packages/Python/lldbsuite/test/expression
apolyakov added a comment.
Sorry, but I still don't understand you. In my thoughts, user specify actions
for success and/or error cases. Success case means that out SBError objects'
status is success(`sb_error.Success() == true`). Error case means similar
except SBError object has fail status.
Author: labath
Date: Tue Jun 19 10:24:03 2018
New Revision: 335060
URL: http://llvm.org/viewvc/llvm-project?rev=335060&view=rev
Log:
Scalar: Use llvm integer conversion functions
StringConvert was the only non-Utility dependency of this class. Getting
rid of it means it will be easy to move this
jingham added a comment.
I think ultimately we should make this presentation of variables as symmetrical
with locals as we can or it's going to confuse users.
I don't think it is necessary for the first version. The first uses, I would
imagine, are to make available some variables in situation
Hey Greg,
I would be hesitant to make any big changes at the moment since it's my
understanding that Zachary is working on a change that would impact all
platforms (specifically for process launching).
That said, I've been looking at some of the other failing tests on Windows and
I can compare
friss added inline comments.
Comment at:
packages/Python/lldbsuite/test/expression_command/xvalue/TestXValuePrinting.py:32
+self.assertTrue(value.GetError().Success())
+self.assertEqual(value.GetValueAsUnsigned(), 0)
+
Could you use a different v
aprantl added a comment.
In https://reviews.llvm.org/D48295#1136692, @apolyakov wrote:
> I don't completely understand what you mean. First of all, what do you mean
> when talking about success_handlers? 'cause if you mean success_handler from
> `Execute` function, then I should say that it doe
apolyakov added a comment.
In https://reviews.llvm.org/D48295#1136663, @aprantl wrote:
> In this design the success_handlers return an exit status *and* set a string
> error. We could unify this by having the handler return an llvm::Error
> (https://llvm.org/doxygen/classllvm_1_1Error.html). Wh
aprantl added a comment.
In this design the success_handlers return an exit status *and* set a string
error. We could unify this by having the handler return an llvm::Error
(https://llvm.org/doxygen/classllvm_1_1Error.html). When it is successful, it
returns Error::success, otherwise it returns
labath updated this revision to Diff 151922.
labath added a comment.
Rebase this patch on trunk. Now this patch is simply about moving GetPythonDir
from Host module to ScriptInterpreterPython.
https://reviews.llvm.org/D48215
Files:
include/lldb/Host/macosx/HostInfoMacOSX.h
include/lldb/Host
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335052: Replace HostInfo::GetLLDBPath with specific
functions (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D48272
Files:
Author: labath
Date: Tue Jun 19 08:09:07 2018
New Revision: 335052
URL: http://llvm.org/viewvc/llvm-project?rev=335052&view=rev
Log:
Replace HostInfo::GetLLDBPath with specific functions
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of f
Author: labath
Date: Tue Jun 19 08:07:22 2018
New Revision: 335051
URL: http://llvm.org/viewvc/llvm-project?rev=335051&view=rev
Log:
Make TestCommandScript.py NO_DEBUG_INFO_TESTCASE
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py
Modif
labath added a comment.
In https://reviews.llvm.org/D48272#1135373, @clayborg wrote:
> Looks good. My only question is do we not require people to only fill in the
> directory portion of the FileSpec anymore for these functions? I am fine with
> way since hopefully FileSpec::AppendPathComponent
A test?
It looks like it should be possible to test this in a similar way to
other CommandCompletion tests
(unittests/Interpreter/TestCompletion.cpp).
On Mon, 18 Jun 2018 at 21:16, Raphael Isemann via lldb-commits
wrote:
>
> Author: teemperor
> Date: Mon Jun 18 13:11:38 2018
> New Revision: 33497
Author: labath
Date: Tue Jun 19 07:23:31 2018
New Revision: 335047
URL: http://llvm.org/viewvc/llvm-project?rev=335047&view=rev
Log:
Attempt to fix windows build broken by r334968
The issue was that there was no dependency from lldb-suite target to liblldb in
the no-framework scenario. This cause
apolyakov updated this revision to Diff 151906.
apolyakov added a comment.
Attached another realization of `CMICmdBase::ReturnMIStatus`. It uses lambda
functions to get user defined actions.
It works, but, as you may see, I had to define `auto error_handler = ...` in
`Execute` function since in
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.
Thanks Jason, good catch!
Repository:
rL LLVM
https://reviews.llvm.org/D48302
___
lldb-commits mailing list
lldb-commits@lists.llv
33 matches
Mail list logo
