dotest is also a potentially fallible layer on top of the SB Api call, but
one that involves *more* behind-the-scenes code between the test and code
being tested.
An lldb-test test would consist, in its entirety, of about 10 lines of
text. I don’t see how it’s possible to beat that from a simplici
We’ve had many instances of flakiness in non pexpect tests (on all
platforms). There’s no obvious pattern to when a test will be flaky.
Whether those are due to dotest or liblldb is an open question, but one
good way of answering those types of questions is to replace one source of
unknown-flakines
out this.
On Mon, Jan 29, 2018 at 5:51 PM Zachary Turner wrote:
> We’ve had many instances of flakiness in non pexpect tests (on all
> platforms). There’s no obvious pattern to when a test will be flaky.
> Whether those are due to dotest or liblldb is an open question, but one
> good way
On Mon, Jan 29, 2018 at 6:11 PM Jim Ingham wrote:
>
> The wider LLVM community tests a very different kind of tool than lldb,
> which leaves me less moved by the argumentum ad verecundiam than I might
> otherwise be.
>
But it's not a different kind of test than this particular test, which is
why
Yea good point. We can probably punt on this for now as it’s just a
nice-to-have
On Thu, Feb 1, 2018 at 1:38 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
>
> Comment at: lit/SymbolFile/PDB/func-symbols.test:4
> +RUN: clang-
Same reason that people use perl for heavy text processing, R for
scientific programming, python for rapid iteration. It’s what they’re built
for. When something is built for a very focused specific problem domain,
the problems in that domain can be expressed very concisely and naturally.
In the c
Zachary Turner wrote:
> Same reason that people use perl for heavy text processing, R for
> scientific programming, python for rapid iteration. It’s what they’re built
> for. When something is built for a very focused specific problem domain,
> the problems in that domain can be expressed ve
Yes but debugging across several api calls is annoying, and the command
line in the log file doesn’t ever work for me
On Wed, Feb 7, 2018 at 6:07 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> If a dotest test fails, you go to the Failure-whatever.l
Looks good. Stuff like this feel free to just commit
On Wed, Feb 7, 2018 at 7:53 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith created this revision.
> asmith added reviewers: zturner, lldb-commits.
> Herald added a subscriber: llvm-commits.
>
> LLDB_TEST_COMPILER is n
I think just remove the preprocessor block. Imagine debugging a Windows
target from a linux host. This function would return false as written
because the host wasn’t Windows
On Thu, Feb 8, 2018 at 12:18 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith added a comment.
>
>
Looks good (but for the _Z case, make sure its length is at least 2)
On Thu, Feb 8, 2018 at 12:33 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith added a comment.
>
> How about this?
>
> if (name == nullptr)
> return false;
>
> return ( (name[0] == '?') || (name[
The problem is that CMAKE_CFG_INTDIR evaluates to something very common,
like “Debug” or “Release”, and replacing a common string like that in a
path creates more problems than it solves in my opinion. What if your build
dir is C:\src\LLDBDebugger\out\Debug\clang.exe? Debug appears twice in this
st
roperty to make the choice explicit is simple
> enough. Currently, the default is to use the just-built compiler (unless a
> path is specified), so we could add LLDB_TEST_JUST_BUILT_CLANG set to ON by
> default to keep the current default settings.
>
> On Thu, Feb 8, 2018 at 9:07 PM,
On Fri, Feb 9, 2018 at 12:19 PM Stiliyana Stamenova <
stiliyana.stamen...@gmail.com> wrote:
> No, we don't need a switch unless we want to be explicit.
>
> I am not sure what you mean by "fix that instead" - the VS generator?
>
What I meant is that if the default behavior (i.e. LLDB_TEST_C_COMPILE
On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > zturner added a comment.
> >
> > In https://reviews.llvm.org/D43048#1005513, @j
Sure I don’t think anyone disputes that, but I thought we were discussing
an ideal end state
On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote:
> >
> >
> >
> > On Mon, Feb 12, 201
No
On Wed, Feb 14, 2018 at 2:46 PM Adrian McCarthy via Phabricator <
revi...@reviews.llvm.org> wrote:
> amccarth added a comment.
>
> Any remaining concerns?
>
>
> https://reviews.llvm.org/D43215
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.l
I wouldn’t use std::bind though, just make a lambda.
On Thu, Feb 22, 2018 at 6:06 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D43662#1016939, @vsk wrote:
>
> > > What do you think about a syntax like:
> > >
> > > lldb
Llvm also separates the Integration tests (test-suite) from the regression
tests. That’s another approach to handling the Cartesian product testing
On Mon, Feb 26, 2018 at 6:01 PM Paul Robinson via Phabricator via
lldb-commits wrote:
> probinson added a comment.
>
> In https://reviews.llvm.org/D3
What about having the macro do the log printing in a function so you can
put the breakpoint in the function?
On Wed, Feb 28, 2018 at 5:56 PM Vedant Kumar via Phabricator <
revi...@reviews.llvm.org> wrote:
> vsk added inline comments.
>
>
>
> Comment at: include/lldb/Utility/Log.h:
Lgtm
On Tue, Mar 6, 2018 at 9:14 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith updated this revision to Diff 137324.
> asmith added a comment.
>
> Add test
>
>
> https://reviews.llvm.org/D44166
>
> Files:
> lit/SymbolFile/PDB/Inputs/SimpleTypesTest.cpp
> lit/Symbol
Shouldn’t it be lldb-dotest? I’m confused about what this target does
On Wed, Mar 14, 2018 at 8:21 AM Davide Italiano via Phabricator <
revi...@reviews.llvm.org> wrote:
> davide accepted this revision.
> davide added a comment.
> This revision is now accepted and ready to land.
>
> LGTM
>
>
> Repo
I think having all parsing functions in a single place will just move the
layering problem elsewhere, since a bunch of conversion functions for
objects from various libraries will be mushed together into one place.
On Wed, Mar 14, 2018 at 11:34 AM Jim Ingham via Phabricator <
revi...@reviews.llvm.
I haven’t had time to look at this in detail yet, but when I originally had
this idea I thought we would use lit’s discovery mechanism to find all .py
files, and then invoke them using dotest.py in single process mode with a
path to a specific file.
Why do we need run lines?
On Wed, Apr 4, 2018 at
On Wed, Apr 4, 2018 at 8:11 AM Jonas Devlieghere via Phabricator <
revi...@reviews.llvm.org> wrote:
> JDevlieghere added a comment.
>
> In https://reviews.llvm.org/D45215#1056917, @zturner wrote:
>
> > I haven’t had time to look at this in detail yet, but when I originally
> had
> > this idea I t
Sure, but getting lit to run one file at a time is a nice incremental step
towards that and can make both patches easier to review.
On Wed, Apr 4, 2018 at 9:02 AM Adrian Prantl wrote:
>
> On Apr 4, 2018, at 8:53 AM, Pavel Labath wrote:
>
>
>
> On Wed, 4 Apr 2018 at 16:47, Zac
I have some ideas for how to run the different variants as separate tests,
but I'll save it for the next RFC :)
On Wed, Apr 4, 2018 at 10:24 AM Jonas Devlieghere
wrote:
>
> > On Apr 4, 2018, at 5:12 PM, Adrian Prantl wrote:
> >
> >
> >
> >> On Apr 4
I think you need to mark this inline otherwise you're going to get multiple
definitions no?
On Mon, Apr 16, 2018 at 11:29 AM Davide Italiano via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: davide
> Date: Mon Apr 16 11:25:57 2018
> New Revision: 330147
>
> URL: http://llvm.org/vie
Well let’s see what Davide and Adrian think. I’m more of an outsider these
days so consider my perspective an llvm-centric one, which would sometimes
(but not always) be the best for lldb
On Wed, Apr 25, 2018 at 12:31 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath adde
t; it.
>
> -- adrian
>
>
> On Apr 25, 2018, at 8:13 AM, Zachary Turner wrote:
>
> Well let’s see what Davide and Adrian think. I’m more of an outsider these
> days so consider my perspective an llvm-centric one, which would sometimes
> (but not always) be the best
Sure multiple run lines can be commands being executed that depend on each
other, but it's very common for a test to have multiple check labels as well
On Wed, Apr 25, 2018 at 9:19 AM Adrian Prantl wrote:
>
> On Apr 25, 2018, at 9:08 AM, Zachary Turner wrote:
>
> But is there
On Wed, Apr 25, 2018 at 9:19 AM Adrian Prantl wrote:
>
> On Apr 25, 2018, at 9:08 AM, Zachary Turner wrote:
>
> But is there a reason why that is more valuable with LLDB than it is with
> LLVM? In LLVM when a test fails it stops and doesn't run subsequent run
> lines
Author: zturner
Date: Fri Mar 17 11:32:43 2017
New Revision: 298099
URL: http://llvm.org/viewvc/llvm-project?rev=298099&view=rev
Log:
Fix some signed/unsigned comparison warnings.
Patch by Hugh Bellamy
Differential Revision: https://reviews.llvm.org/D30926
Modified:
lldb/trunk/source/Core/Fo
Author: zturner
Date: Fri Mar 17 11:33:37 2017
New Revision: 298100
URL: http://llvm.org/viewvc/llvm-project?rev=298100&view=rev
Log:
CMake requires normalized paths when appending.
Patch by Hugh Bellamy
Differential Revision: https://reviews.llvm.org/D30927
Modified:
lldb/trunk/cmake/module
Author: zturner
Date: Sun Mar 19 00:48:01 2017
New Revision: 298202
URL: http://llvm.org/viewvc/llvm-project?rev=298202&view=rev
Log:
Fix unit test compilation failure.
Modified:
lldb/trunk/unittests/Interpreter/TestCompletion.cpp
Modified: lldb/trunk/unittests/Interpreter/TestCompletion.cpp
Author: zturner
Date: Sun Mar 19 00:48:47 2017
New Revision: 298203
URL: http://llvm.org/viewvc/llvm-project?rev=298203&view=rev
Log:
Remove FileSystem::MakeDirectory.
Have callers use llvm::sys::fs::create_directory() instead.
Differential Revision: https://reviews.llvm.org/D31086
Modified:
Author: zturner
Date: Sun Mar 19 00:49:43 2017
New Revision: 298205
URL: http://llvm.org/viewvc/llvm-project?rev=298205&view=rev
Log:
Remove FileSystem::Get/SetFilePermissions
Differential Revision: https://reviews.llvm.org/D31089
Modified:
lldb/trunk/include/lldb/Host/FileSystem.h
lldb/
Author: zturner
Date: Sun Mar 19 01:00:31 2017
New Revision: 298206
URL: http://llvm.org/viewvc/llvm-project?rev=298206&view=rev
Log:
Fix syntax error when building with editline support.
Modified:
lldb/trunk/source/Host/common/Editline.cpp
Modified: lldb/trunk/source/Host/common/Editline.cp
The reason was because two different tests from two different unittest
executables need it, but we have no good way to share code across unittests
like this. Open to suggestions though
On Mon, Mar 20, 2017 at 4:02 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added in
n depend on? The llvm folder-globbing means we would
> have to put it in a subfolder (unittests/Utility/lib ?), which makes is
> somewhat annoying, but I still think that's better than having the test
> code in the main module.
>
> On 20 March 2017 at 13:04, Zachary Turner wrote:
Author: zturner
Date: Mon Mar 20 18:33:18 2017
New Revision: 298322
URL: http://llvm.org/viewvc/llvm-project?rev=298322&view=rev
Log:
Add a function to MD5 a file's contents.
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but fo
Author: zturner
Date: Mon Mar 20 18:54:26 2017
New Revision: 298324
URL: http://llvm.org/viewvc/llvm-project?rev=298324&view=rev
Log:
[analyze-project-deps.py] Add the ability to list all cycles.
This analyzes the dependency graph and computes all minimal
cycles. Equivalent cycles that differ on
Author: zturner
Date: Mon Mar 20 18:54:54 2017
New Revision: 298325
URL: http://llvm.org/viewvc/llvm-project?rev=298325&view=rev
Log:
Delete LLDB's MD5 code. Use LLVM instead.
Differential Revision: https://reviews.llvm.org/D31108
Modified:
lldb/trunk/include/lldb/Host/FileSystem.h
lldb/
Author: zturner
Date: Mon Mar 20 18:55:20 2017
New Revision: 298326
URL: http://llvm.org/viewvc/llvm-project?rev=298326&view=rev
Log:
[Support] Fill the file_status struct with link count.
Differential Revision: https://reviews.llvm.org/D31110
Modified:
lldb/trunk/source/Host/common/File.cpp
Author: zturner
Date: Mon Mar 20 23:01:04 2017
New Revision: 298334
URL: http://llvm.org/viewvc/llvm-project?rev=298334&view=rev
Log:
Delete various lldb FileSystem functions.
Use LLVM's equivalent versions instead.
Differential Revision: https://reviews.llvm.org/D3
Modified:
lldb/trunk
Author: zturner
Date: Mon Mar 20 23:01:59 2017
New Revision: 298335
URL: http://llvm.org/viewvc/llvm-project?rev=298335&view=rev
Log:
Delete some dead code in HostInfo.
Modified:
lldb/trunk/include/lldb/Host/HostInfoBase.h
lldb/trunk/include/lldb/Host/freebsd/HostInfoFreeBSD.h
lldb/tr
Author: zturner
Date: Tue Mar 21 00:47:57 2017
New Revision: 298340
URL: http://llvm.org/viewvc/llvm-project?rev=298340&view=rev
Log:
Resubmit r298334 after fixing OSX build errors.
Hopefully this works, I can't test since I don't have Mac
hardware, however.
Modified:
lldb/trunk/include/lldb
I found it, but in the future would you mind including a link to the
buildbot?
On Mon, Mar 20, 2017 at 9:57 PM Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jmolenda
> Date: Mon Mar 20 23:45:10 2017
> New Revision: 298338
>
> URL: http://llvm.org/viewvc/llvm-proje
Thanks for the suggestions! Not sure if I'll be able to make those changes
before tomorrow EOD, and after that I will be out for ~2 weeks, so if time
doesn't permit, I may not follow up with another patch until after I get
back.
On Tue, Mar 21, 2017 at 11:19 AM Jim Ingham via Phabricator <
revi..
Author: zturner
Date: Tue Mar 21 13:25:04 2017
New Revision: 298412
URL: http://llvm.org/viewvc/llvm-project?rev=298412&view=rev
Log:
Move StringList from Core -> Utility.
Added:
lldb/trunk/include/lldb/Utility/StringList.h
lldb/trunk/source/Utility/StringList.cpp
Removed:
lldb/trunk/
Author: zturner
Date: Tue Mar 21 13:45:42 2017
New Revision: 298419
URL: http://llvm.org/viewvc/llvm-project?rev=298419&view=rev
Log:
Fix build broken by StringList move.
Modified:
lldb/trunk/include/lldb/Utility/StringList.h
lldb/trunk/source/Symbol/Symtab.cpp
Modified: lldb/trunk/inclu
Author: zturner
Date: Tue Mar 21 17:46:46 2017
New Revision: 298455
URL: http://llvm.org/viewvc/llvm-project?rev=298455&view=rev
Log:
[deps script] Sort cycles by the difficulty of breaking.
When passing --discover-cycles and --show-counts, it displays
the number of dependencies between each hop
Author: zturner
Date: Tue Mar 21 19:27:24 2017
New Revision: 298465
URL: http://llvm.org/viewvc/llvm-project?rev=298465&view=rev
Log:
Delete the remainder of platform specific code in FileSpec.
Differential Revision: https://reviews.llvm.org/D31129
Added:
lldb/trunk/unittests/Utility/Mocks/
Author: zturner
Date: Tue Mar 21 19:27:54 2017
New Revision: 298466
URL: http://llvm.org/viewvc/llvm-project?rev=298466&view=rev
Log:
Break the cycle between Host and PluginProcessUtility.
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this
Author: zturner
Date: Wed Mar 22 12:08:25 2017
New Revision: 298519
URL: http://llvm.org/viewvc/llvm-project?rev=298519&view=rev
Log:
Delete TestLLVM.py
This was added to workaround a limitation in LLVM's implementation
of getting the current user's home directory, since it would
only look at the
Author: zturner
Date: Wed Mar 22 12:33:23 2017
New Revision: 298526
URL: http://llvm.org/viewvc/llvm-project?rev=298526&view=rev
Log:
Resubmit "Delete the remainder of platform specific code in FileSpec."
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limit
Author: zturner
Date: Wed Mar 22 13:04:20 2017
New Revision: 298530
URL: http://llvm.org/viewvc/llvm-project?rev=298530&view=rev
Log:
[analyze deps] Also show cycle islands.
We currently display a list of all minimal cycles, but it's
useful to be able to see the big picture impact of these cycles
Author: zturner
Date: Wed Mar 22 13:23:14 2017
New Revision: 298535
URL: http://llvm.org/viewvc/llvm-project?rev=298535&view=rev
Log:
[analyze deps] Show incoming and outgoing counts on island members.
Modified:
lldb/trunk/scripts/analyze-project-deps.py
Modified: lldb/trunk/scripts/analyze-
Author: zturner
Date: Wed Mar 22 14:24:17 2017
New Revision: 298541
URL: http://llvm.org/viewvc/llvm-project?rev=298541&view=rev
Log:
Remove dead include from GoASTContext.cpp.
This #include was the cause of a dependency from Symbol ->
DataFormatters. However, nothing from the header was being
u
Author: zturner
Date: Wed Mar 22 18:33:16 2017
New Revision: 298561
URL: http://llvm.org/viewvc/llvm-project?rev=298561&view=rev
Log:
Delete some more dead includes.
This breaks the cycle between Target and PluginLanguageC++, reducing
the overall cycle count from 43 to 42.
Modified:
lldb/tru
I'm ooo for ~2 weeks so I can't really do code reviews unfortunately
On Sat, Mar 25, 2017 at 6:23 AM Chris Bieneman via Phabricator <
revi...@reviews.llvm.org> wrote:
> beanz added a comment.
>
> Xcode is pretty magic to me. I don't know how to do much of anything in it
> other than build. I think
Author: zturner
Date: Thu Apr 6 13:12:24 2017
New Revision: 299676
URL: http://llvm.org/viewvc/llvm-project?rev=299676&view=rev
Log:
iwyu fixes on lldbUtility.
This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). T
Author: zturner
Date: Thu Apr 6 15:51:22 2017
New Revision: 299705
URL: http://llvm.org/viewvc/llvm-project?rev=299705&view=rev
Log:
Try to fix FreeBSD build after iwyu changes.
Modified:
lldb/trunk/source/Host/freebsd/HostInfoFreeBSD.cpp
Modified: lldb/trunk/source/Host/freebsd/HostInfoFre
Author: zturner
Date: Thu Apr 6 16:57:39 2017
New Revision: 299718
URL: http://llvm.org/viewvc/llvm-project?rev=299718&view=rev
Log:
Fix build failure in unit test.
Modified:
lldb/trunk/unittests/Core/BroadcasterTest.cpp
Modified: lldb/trunk/unittests/Core/BroadcasterTest.cpp
URL:
http://l
Author: zturner
Date: Thu Apr 6 17:18:59 2017
New Revision: 299719
URL: http://llvm.org/viewvc/llvm-project?rev=299719&view=rev
Log:
Try to fix FreeBSD build after IWYU changes.
Modified:
lldb/trunk/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
Modified: lldb/trunk/source/Plugins/Proces
Agreed. Before I clang-formatted it, it looked fine, because each
definition was on a single line. But clang-format made them 3 lines each.
So yea, we should definitely merge them. I was copy/pasting the output
from IWYU, which is why it looks this way. Thanks for bringing it up
On Thu, Apr 6,
Lgtm
On Mon, Apr 10, 2017 at 11:03 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> labath created this revision.
> Herald added a subscriber: mgorny.
>
> The files there can always be referred to using their full path, which
> is what most of the code has been doing already, so this mak
Just to be clear, this patch was only intended to be a starting point. I
didn't run the test suite or do anything other than verify that the core
loaded. ArchSpec is a pretty core class so touching it in this manner is
likely to have many side effects that you'll need to work out.
Most likely so m
ure
> exactly which it might be.
>
> If this can't be tested through the unit test framework, it would be easy
> to add an SB API test case, see above.
>
> Thanks
>
>
>
> > On Mar 12, 2017, at 11:18 AM, Zachary Turner via lldb-commits <
> lldb-commits@li
Author: zturner
Date: Fri Apr 14 21:44:53 2017
New Revision: 300386
URL: http://llvm.org/viewvc/llvm-project?rev=300386&view=rev
Log:
Fix crash when completing in the current directory.
Modified:
lldb/trunk/source/Commands/CommandCompletions.cpp
lldb/trunk/unittests/Interpreter/TestComple
Should be fixed in r300386, let me know if you're still experiencing
problems.
On Tue, Apr 11, 2017 at 5:59 PM Zachary Turner wrote:
> Thanks for the heads up, I'll try to look at this tomorrow.
>
> On Tue, Apr 11, 2017 at 5:55 PM Jason Molenda wrote:
>
>> I notic
Does 0 mean infinite here? If so are the newly introduced semantics here
still correct?
On Sat, Apr 15, 2017 at 3:34 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> labath accepted this revision.
> labath added a comment.
> This revision is now accepted and ready to land.
>
> looks good
We already have this exact code in lldb/cmake/LLDBConfig.txt. This fix
looks fine, but I see no reason to have it twice, so can you delete the
LLDB version?
On Mon, Apr 17, 2017 at 7:01 AM Kamil Rytarowski via Phabricator <
revi...@reviews.llvm.org> wrote:
> krytarowski added a comment.
>
> Is t
Note that getAsInteger returns false on success, so be careful!
On Thu, Apr 20, 2017 at 6:09 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D32149#731920, @krytarowski wrote:
>
> > In https://reviews.llvm.org/D32149#7318
On Thu, Apr 20, 2017 at 9:00 PM Greg Clayton via Phabricator via
lldb-commits wrote:
> clayborg requested changes to this revision.
> clayborg added a comment.
> This revision now requires changes to proceed.
>
> Very close. A few misuses of ConstString and this will be good to go.
>
>
>
> ==
Which C compilers do we have that are not capable of producing ELF
binaries? GCC on Windows maybe? That's not even a supported test
configuration.
On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.ll
wrote:
> Microsoft Visual C++ first comes to my mind.
>
> On Mon, Apr 24, 2017 at 2:31 PM, Zachary Turner
> wrote:
>
>> Which C compilers do we have that are not capable of producing ELF
>> binaries? GCC on Windows maybe? That's not even a supported test
>> c
I suppose that's a reasonable concern. I also didn't notice that this was
a unittest, I assumed it was a lit test.
If that's the case, is there any way to use llvm/Object to construct a
minimal ELF file in memory with a hardcoded symbol in the BSS section. It
can even be missing certain critical
Other alternatives though include adding a function to StringMap which
gives us what we need, and having this function do the pointer hacking, or
simply calling strlen.
On Wed, Apr 26, 2017 at 11:03 AM Scott Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> scott.smith added inline comme
There is a file in the repo called git-clang-format. Make sure that file
is on your PATH somewhere, then just run `git clang-format`. It will only
touch lines that are part of your diff, and leave surrounding lines alone.
When making a diff, we only want to clang-format the lines we touched, not
In case it's not obvious, note the space in the command I said to run.
`git-clang-format` has a dash, and when you run `git clang-format` (with a
space), it will run the file with the dash.
On Thu, Apr 27, 2017 at 8:58 AM Zachary Turner wrote:
> There is a file in the repo called g
"(lldb) settings set target.cache-priming foo"
On Thu, Apr 27, 2017 at 11:53 AM Scott Smith via Phabricator via
lldb-commits wrote:
> scott.smith added a comment.
>
> In https://reviews.llvm.org/D32598#739804, @jingham wrote:
>
> > Instead of having the cache priming be determined by platform or
Then make it ready :-/
Why does LLDB need llvm::ThreadPool for this to work? I proposed a single
function that is not dependent on any particular instance of a thread pool.
template
void parallel_for_each(Range &&R, Func &&F) {
// call F(Index, *Iter) for every item in R.
}
std::vector Foos
Can you rewrite the exe path computation to use os.path.join so we're not
assuming posix syntax?
On Tue, May 2, 2017 at 11:11 PM vignesh balu via Phabricator via
lldb-commits wrote:
> vbalu updated this revision to Diff 97550.
> vbalu added a comment.
>
> Corrected the code. Now this test will fa
Don't even need a template. Use llvm::function_ref
On Fri, May 5, 2017 at 4:30 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL302223: Add TaskMap for iterating a function over a set
Take a look at ErrorChecking.h in llvm, it contains some useful macros for
using expected and error
On Mon, May 8, 2017 at 5:42 AM Kamil Rytarowski via Phabricator via
lldb-commits wrote:
> krytarowski added inline comments.
>
>
>
> Comment at: unittests/tools/lldb-server/inferio
Author: zturner
Date: Fri May 12 00:48:54 2017
New Revision: 302874
URL: http://llvm.org/viewvc/llvm-project?rev=302874&view=rev
Log:
Fix Linux Buildbot.
Modified:
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cpp
Modified: lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cp
Author: zturner
Date: Fri May 12 00:49:54 2017
New Revision: 302875
URL: http://llvm.org/viewvc/llvm-project?rev=302875&view=rev
Log:
Update StructuredData::String to return StringRefs.
It was returning const std::string& which was leading to
unnecessary copies all over the place, and preventing
Yea, I think at best we can just put a doxygen comment above the function
explaining it
On Sat, May 13, 2017 at 11:10 PM Kamil Rytarowski via Phabricator <
revi...@reviews.llvm.org> wrote:
> krytarowski added a comment.
>
> It's not that perfectly clear to me that `SetStatus()` returns
> `Succeede
Indeed, ideally there is no bool return value and we just write return
make_error("foo")
On Mon, May 15, 2017 at 5:58 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> I think this is a step in the right direction. Besides reducing
> boilerplate, this
Even though it creates a different TaskGroup for each one, TaskGroup itself
just says getDefaultExecutor, and that returns a global instance. On
Windows this will work because it all delegates to an OS thing that's sort
of like libdispatch and that does support recursion, but the thread pool
execu
Having the construction accept an Error is probably fine, because you have
to std::move it anyway, which means you know you're giving up ownership
On Wed, May 17, 2017 at 3:08 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.o
Lgtm
On Mon, May 22, 2017 at 6:49 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
>
> A change in swig 3.0.9 has caused it to generate modules incompatible
> with us using them as __init__.py (bug #769). Swig 3.0.11 adds a setting
> to help
> fix
Or just use a std vector
On Fri, May 26, 2017 at 7:00 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
>
> Comment at:
> source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1304
> + // Allocate the response
I see. In that case, at least store it in a std::unique_ptr.
On Mon, May 29, 2017 at 12:22 AM Ravitheja Addepally via Phabricator <
revi...@reviews.llvm.org> wrote:
> ravitheja added a comment.
>
> Hello, the reason I switched to allocating with new (std::nothrow)
> uint8_t[byte_count]; was beca
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
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
king of some other good
> I'm missing?
>
> Jim
>
>
> > On May 31, 2017, at 10:37 AM, Zachary Turner via Phabricator via
> lldb-commits wrote:
> >
> > zturner added a comment.
> >
> > In https://reviews.llvm.org/D32930#767820, @beanz wrote:
> &
de that nobody understands
and nobody really maintains / improves.
On Wed, May 31, 2017 at 1:45 PM Jim Ingham wrote:
>
> > On May 31, 2017, at 12:22 PM, Zachary Turner wrote:
> >
> > Writing tests that are
> >
> > A) as easy as possible to write and understand
&
at 2:02 PM Zachary Turner wrote:
> This hypothetical DSL could still run SB API statements. I don't
> necessarily think it *should*, since what the SB API does and what the
> commands do are very different (for example SBTarget.Create() does
> something entirely different than &q
301 - 400 of 3010 matches
Mail list logo
