DenseSet<> provides a method named find_as which lets you use an arbitrary
type as the lookup key. The only requirement is that your DenseMapInfo<>
that you've specialized provide two methods for each key type you want to
use. So using this approach, even if you have a DenseSet S,
you can still w
clayborg added a comment.
Zach made some comments via e-mail:
> Couple of things:
>
> 1. Unless you really really want iteration over this map to be in some
> deterministic order, better to use unordered_map. And if you do want it to
> be in some deterministic order, you should provide a comp
Couple of things:
1) Unless you really really want iteration over this map to be in some
deterministic order, better to use unordered_map. And if you do want it to
be in some deterministic order, you should provde a comparison function, as
the default one is probably not what you want.
2) std::ma
chris...@zoulas.com (Christos Zoulas) wrote on 30.05.2017 17:46:58:
> I am sorry to say that this is my fault and this sucks. I accepted
> some patches that broke binary compatibility in a way that it is not
> user visible. Basically you seem to have version of libedit that is
> between the narrow
beanz accepted this revision.
beanz added a comment.
One small comment below. In general I agree with the thoughts here, and I think
that this is a huge step forward for testing the debug server components.
I also agree with Zachary in principal that it would be nice to come up with
lit-based t
clayborg added a comment.
The other option for fixing the problem with showing the wrong variables in the
backtraces would be to make up a new frame-format string that is used for
uniqued stack frames and use that format when showing uniqued stack frames:
(lldb) settings show frame-format-uni
clayborg added a comment.
Clicked submit too early with last comments. After seeing how we previously
needed to create a temp UniqueStack just to do the lookup, and also how
UniqueStack make its thread index ID list mutable, a better solution is to use
a std::map as shown in the inlined comment
clayborg added a comment.
Much cleaner. After seeing how we must construct a UniqueStack just so we can
search for it, an even cleaner solution would be to make unique_stacks into:
std::map
https://reviews.llvm.org/D33426
___
lldb-commits mailin
emaste added a comment.
Generally LGTM with two questions inline.
Comment at:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py:45
+os.mkdir(os.path.join(os.getcwd(),'newdir'))
+self.buildProgram('main.cpp','newdir/proc_attach')
when i try to build LLDB in xcode , i get this error:
"The specified item could not be found in the keychain"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Any suggestions ?
thanks,
vbalu
On Tue, May 16, 2017 at 12:51 PM, vignesh balu via Phabricator <
revi...@reviews.llvm.org> wrote:
> vbalu added a comment.
>
> In https://reviews.llvm.org/D32732#753348, @jingham wrote:
>
> > That looks like the right way to do it. What was your thinking behind
>
11 matches
Mail list logo
