This revision was automatically updated to reflect the committed changes.
Closed by commit rL327110: Move option parsing out of the Args class (authored
by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D43837?vs=136355&id=1377
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Nope.
https://reviews.llvm.org/D43837
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
labath added a comment.
Is there anything else you wanted me to do here?
https://reviews.llvm.org/D43837
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham added a comment.
The separate gtest directories don't get build separately the way Todd set the
Xcode project up. The tests get built into one combo .a file that links to
liblldbcore.a, and then into the test binary. So the Xcode build wouldn't see
that failure.
Since you are buildin
labath updated this revision to Diff 136355.
labath added a comment.
Add a slightly longer comment to the Parse function operation.
https://reviews.llvm.org/D43837
Files:
include/lldb/Interpreter/Args.h
include/lldb/Interpreter/Options.h
packages/Python/lldbsuite/test/functionalities/comp
labath added a comment.
In https://reviews.llvm.org/D43837#1022554, @jingham wrote:
> Okay, that sounds good then. Will you enforce the rule about the Utilities
> directory socially or by some mechanism?
You will get a link error because the Utility unittest executable will have
missing symb
zturner added a comment.
In https://reviews.llvm.org/D43837#1022554, @jingham wrote:
> Okay, that sounds good then. Will you enforce the rule about the Utilities
> directory socially or by some mechanism?
If you mean the rule that Utility can't depend on anything else, I think it's
enforced
jingham added a comment.
Okay, that sounds good then. Will you enforce the rule about the Utilities
directory socially or by some mechanism?
https://reviews.llvm.org/D43837
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llv
labath added inline comments.
Comment at: include/lldb/Interpreter/Options.h:123-126
+ llvm::Expected Parse(const Args &args,
+ ExecutionContext *execution_context,
+ lldb::PlatformSP platform_sp,
+
zturner added a comment.
It would be nice if we could eventually get rid of the need to pass in a
platform and execution context here, but that's work for another day.
Comment at: include/lldb/Interpreter/Options.h:123-126
+ llvm::Expected Parse(const Args &args,
+
labath added a comment.
In https://reviews.llvm.org/D43837#1022430, @jingham wrote:
> I still worry a bit because there's another unstated responsibility for Args
> which is that even though it is going to get used at a very high level in
> lldb it has to NOT depend on anything you don't want l
zturner added inline comments.
Comment at: include/lldb/Interpreter/Options.h:123-126
+ llvm::Expected Parse(const Args &args,
+ ExecutionContext *execution_context,
+ lldb::PlatformSP platform_sp,
+
jingham added a comment.
I still worry a bit because there's another unstated responsibility for Args
which is that even though it is going to get used at a very high level in lldb
it has to NOT depend on anything you don't want lldb-server to depend on. That
seems like a more slippery respons
labath added a comment.
In https://reviews.llvm.org/D43837#1022303, @jingham wrote:
> I don't have any objections to the contents of this patch per se. But I
> wonder if having to do all this work to separate the uses of Args from the
> options parser so we don't drag it in in some low level u
jingham added a comment.
I don't have any objections to the contents of this patch per se. But I wonder
if having to do all this work to separate the uses of Args from the options
parser so we don't drag it in in some low level uses doesn't rather mean the
Args class was not appropriate for us
labath created this revision.
labath added reviewers: davide, jingham, zturner.
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the c
16 matches
Mail list logo
