Author: zturner
Date: Thu Dec 8 19:08:29 2016
New Revision: 289164
URL: http://llvm.org/viewvc/llvm-project?rev=289164&view=rev
Log:
Modernize the Args access pattern in a few more commands.
Modified:
lldb/trunk/include/lldb/Interpreter/CommandObject.h
lldb/trunk/source/Commands/CommandO
Author: zturner
Date: Thu Dec 8 19:20:58 2016
New Revision: 289168
URL: http://llvm.org/viewvc/llvm-project?rev=289168&view=rev
Log:
Fix some occurrences of passing StringRef to Printf.
Hopefully these will all disappear in the future once we move
to formatv.
Modified:
lldb/trunk/source/Com
Author: zturner
Date: Thu Dec 8 23:46:41 2016
New Revision: 289188
URL: http://llvm.org/viewvc/llvm-project?rev=289188&view=rev
Log:
Remove some more uses of Args::GetArgumentAtIndex.
Modified:
lldb/trunk/source/Commands/CommandObjectMultiword.cpp
lldb/trunk/source/Commands/CommandObject
Seems reasonable, I'll make a FileSpec formatter and update the patch
On Fri, Dec 9, 2016 at 4:03 PM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg requested changes to this revision.
> clayborg added a comment.
> This revision now requires changes to proceed.
>
> I wou
I would say format provider should be the default way to add formatting for
a commonly formatted type. Member function syntax is used to implement
adaptors that allow you to override formatting behavior of a type that
already has a provider.
One nice thing about F and D would be this:
formatv("Di
To elaborate about member function vs format provider, decoupling types
from the way they're formatted seems like a good design practice in
general. For example, you might want to add support for formatting a class
which you don't have the code to. Sure, you can do it one way whenever
possible an
Lgtm thanks
On Tue, Dec 13, 2016 at 2:33 AM Hafiz Abid Qadeer via Phabricator <
revi...@reviews.llvm.org> wrote:
> abidh created this revision.
> abidh added a reviewer: zturner.
> abidh added a subscriber: lldb-commits.
>
> This code was probably needed to support VS2013 and is not needed now. I
On Wed, Dec 14, 2016 at 1:41 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> Modified: lldb/trunk/source/API/SBFrame.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBFrame.cpp?rev=289711&r1=289710&r2=289711&view=diff
>
> =
Looks good
On Thu, Dec 15, 2016 at 2:16 AM Hafiz Abid Qadeer via Phabricator <
revi...@reviews.llvm.org> wrote:
> abidh added a comment.
>
> In https://reviews.llvm.org/D27759#622332, @labath wrote:
>
> > Yeah, I meant using it everywhere as a generic "am I on windows,
> regardless of the compiler
I think this was lgtm'ed wasn't it?
On Thu, Dec 15, 2016 at 9:46 AM Luke Drummond via Phabricator <
revi...@reviews.llvm.org> wrote:
> ldrumm marked 2 inline comments as done.
> ldrumm added a comment.
>
> ping
>
>
> https://reviews.llvm.org/D26757
>
>
>
>
Author: zturner
Date: Thu Dec 15 22:27:00 2016
New Revision: 289922
URL: http://llvm.org/viewvc/llvm-project?rev=289922&view=rev
Log:
Add methods to enable using formatv syntax in LLDB.
This adds formatv-backed formatting functions in various
places in LLDB such as StreamString, logging, construc
So I ran into a nasty problem doing the rest of the conversions and at the
moment I'm not sure if there's even a workaround. So this is on hold while
I think about it.
On Thu, Dec 15, 2016 at 8:06 PM Zachary Turner via Phabricator <
revi...@reviews.llvm.org> wrote:
> zturner added a comment.
>
>
Author: zturner
Date: Fri Dec 16 15:35:12 2016
New Revision: 289994
URL: http://llvm.org/viewvc/llvm-project?rev=289994&view=rev
Log:
Fix compiler warning.
Modified:
lldb/trunk/source/Commands/CommandObjectMemory.cpp
Modified: lldb/trunk/source/Commands/CommandObjectMemory.cpp
URL:
http://l
Hi Michal,
It looks like this patch may have broken this bot.
http://lab.llvm.org:8080/green/job/lldb_build_test/23767/consoleFull#-1083450927b825e790-484f-4586-af29-73c4754ff671
What do you think?
On Mon, Jan 2, 2017 at 10:31 AM Michal Gorny via lldb-commits <
lldb-commits@lists.llvm.org> wrote
Honestly I would just assume we blanket kill FILE* across the entire
codebase. It's non-portable, doesn't interoperate with Python 3, doesn't
interoperate with C++ library facilities, and is clunky to deal with on
Windows since most of the useful APIs won't accept one.
On Wed, Jan 4, 2017 at 2:04
Author: zturner
Date: Fri Jan 6 16:05:35 2017
New Revision: 291291
URL: http://llvm.org/viewvc/llvm-project?rev=291291&view=rev
Log:
Install lldb Python module on Windows.
Patch by Vadim Chugunov
Differential Revision: https://reviews.llvm.org/D27476
Modified:
lldb/trunk/scripts/CMakeLists.
Official Lgtm
On Wed, Jan 11, 2017 at 4:48 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D28519#641938, @clayborg wrote:
>
> > You can't add anything extra to the AsCString() since it returns a
> "const char *". You can
Sorry forgot about this, looks good
On Mon, Jan 23, 2017 at 7:55 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> Any objections to this, Zach?
>
>
> https://reviews.llvm.org/D28858
>
>
>
>
___
lldb-commits
Thanks for the clarification, I wrote "try to convert" there because I
didn't look closely enough to see what problem it was solving. Since it
seems to be specific to ValueObject (which a grep confirms), we may be able
to just move the code for SharingPtr next to ValueObject. That said,
SharingPt
llvm::Error only enforces checking at the point that it goes out of scope.
So the example you mention should be supported, as long as you propagate
the value all the way up and don't destroy it. There's also ways to
explicitly ignore an Error (similar to casting to void to make the compiler
not war
Yea, there may be value in both. If i ever tried to do this I'd probably
take the approach of converting all the obvious cases first that should
enforce checking and then see what's left. Then we could use llvm:Error and
lldb::Status, or something
On Tue, Jan 31, 2017 at 5:39 PM Jim Ingham wrote:
Are you interested in seeing the followup patches for review (moving
classes from Core -> Utility etc), or does it sound reasonable just based
on my description?
On Tue, Jan 31, 2017 at 6:05 PM Jim Ingham wrote:
> BTW, not to exclude the positive because it doesn't need discussing: all
> the res
Correct, I'm not doing any of the "long term" stuff now, I was just
thinking out loud with that.
On Wed, Feb 1, 2017 at 10:49 AM Jim Ingham wrote:
> I don't think any of this should be terribly controversial. The "Long
> term" part of the proposals might be, but that's not what you're talking
>
Author: zturner
Date: Wed Feb 1 13:45:14 2017
New Revision: 293806
URL: http://llvm.org/viewvc/llvm-project?rev=293806&view=rev
Log:
Break some dependencies in lldbUtility.
Differential Revision: https://reviews.llvm.org/D29359
Removed:
lldb/trunk/include/lldb/Utility/ConvertEnum.h
lldb
Derp. Thanks for catching that!
On Wed, Feb 1, 2017 at 2:41 PM Jason Molenda wrote:
> You need some break;s.
>
>
> -const char *lldb_private::GetVoteAsCString(Vote vote) {
> - switch (vote) {
> - case eVoteNo:
> -return "no";
> - case eVoteNoOpinion:
> -return "no opinion";
> - case
Compiles on Windows, I will watch the bots to see if anything breaks on
Linux/ OSX.
On Fri, Feb 3, 2017 at 3:03 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath accepted this revision.
> labath added a comment.
> This revision is now accepted and ready to land.
>
> look
Right, one of the suggestions I mentioned first was to have comments in the
headers that mention the ability to format the class, or to have the
formatters defined in the same header file as the object. So you look at
the definition of FileSpec, and you learn about the formatter for FileSpec.
On
Yes, a centralized list would be nice
On Fri, Feb 3, 2017 at 5:27 PM Jim Ingham wrote:
> That doesn't help me if I don't know that Format takes formatters and that
> various lldb objects take formatters and here are all the formatters we
> have. And it would be kinder to have the list of availab
Author: zturner
Date: Mon Feb 6 12:31:44 2017
New Revision: 294210
URL: http://llvm.org/viewvc/llvm-project?rev=294210&view=rev
Log:
Get rid of Error::PutToLog().
Instead just rely on LLDB_LOG().
This is part of an effort to sort out dependency hell in LLDB.
Error is in Utility, but Log is in C
Author: zturner
Date: Mon Feb 6 12:49:16 2017
New Revision: 294213
URL: http://llvm.org/viewvc/llvm-project?rev=294213&view=rev
Log:
Try to fix build on non-Windows platforms.
Modified:
lldb/trunk/source/Host/common/Host.cpp
Modified: lldb/trunk/source/Host/common/Host.cpp
URL:
http://llvm
Aside from the thread stuff, nothing seems particularly risky about this
change. Did the thread-local stuff you removed have anything to do with
the -t option to the log command?
On Wed, Feb 8, 2017 at 9:15 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comme
Is it possible to add some unittests for this? In addition to just
tests=good, it would also serve as documentation for the new api
On Mon, Feb 13, 2017 at 9:09 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> Herald added a subscriber: aprantl.
Author: zturner
Date: Tue Feb 14 13:07:01 2017
New Revision: 295091
URL: http://llvm.org/viewvc/llvm-project?rev=295091&view=rev
Log:
Use StringRef and APFloat instead of lldb/StringConvert.h
Modified:
lldb/trunk/source/Utility/JSON.cpp
Modified: lldb/trunk/source/Utility/JSON.cpp
URL:
http
Indeed it should, but unfortunately this is a hand maintained project, and
I don't have a Mac.
Usually in these cases the first person to notice the Xcode project is
broken just submits a fix for it
On Tue, Feb 14, 2017 at 11:27 PM Boris Ulasevich via Phabricator <
revi...@reviews.llvm.org> wrote:
On Wed, Feb 15, 2017 at 5:54 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
>
> Comment at: lldb/source/Utility/VASprintf.cpp:18
> + va_list args) {
> + llvm::SmallString<16> error("");
> +
>
Author: zturner
Date: Thu Feb 16 13:38:21 2017
New Revision: 295368
URL: http://llvm.org/viewvc/llvm-project?rev=295368&view=rev
Log:
Finish breaking the dependency from Utility.
Differential Revision: https://reviews.llvm.org/D29964
Added:
lldb/trunk/include/lldb/Host/PseudoTerminal.h
l
Modified: lldb/trunk/source/Host/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/CMakeLists.txt?rev=295368&r1=295367&r2=295368&view=diff
==
--- lldb/trunk/source/Host/CMakeLists.txt (original
Author: zturner
Date: Thu Feb 16 14:15:26 2017
New Revision: 295369
URL: http://llvm.org/viewvc/llvm-project?rev=295369&view=rev
Log:
Fix build
Modified:
lldb/trunk/source/Utility/VASprintf.cpp
lldb/trunk/unittests/Utility/VASprintfTest.cpp
Modified: lldb/trunk/source/Utility/VASprintf.c
e was something that would have been already
caught by running the unit tests on windows, which leads me to believe
you didn't run them before submission.
Thanks,
pl
2017-02-16 20:15 GMT+00:00 Zachary Turner via lldb-commits
:
> Author: zturner
> Date: Thu Feb 16 14:15:26 2017
>
Yea if this isn't urgent, can we wait for my other changes to go in?
Llvm does support mapping writable, but not through the same interface. So
it should still work
On Wed, Feb 22, 2017 at 6:43 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a reviewer: zturner.
I left out unit tests since we'd essentially be duplicating the unit tests
of MemoryBuffer, and because it involves the file system (also this is
temporary code until DataBuffer stuff goes away). Lmk if you disagree
though
On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator <
revi...@revie
I am going to move the constructor to private for now, this should
eliminate any disagreement about whether to add null checks, as it is now
literally impossible to construct one with a null pointer. For now this
doesn't matter since nobody is even using the MemoryBuffer constructor
except from in
Author: zturner
Date: Fri Feb 24 12:56:49 2017
New Revision: 296159
URL: http://llvm.org/viewvc/llvm-project?rev=296159&view=rev
Log:
Delete DataBufferMemoryMap.
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which
I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not
necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on
various factors such as whether you specify the IsVolatile flag, how big
the file is, and maybe a few other things.
After this change we have DataBuff
There may be some cases where we're no longer mmaping where we used to, but
looking at LLVM's implementation, that would only happen if the file is
fairly small, and there's a comment in LLVM explaining why they don't mmap
small files. So I think that's actually an improvement for LLDB (although
I
Oh that wasn't in response to the comment about wrapper classes, that was
just a general comment about the fact that we lose logging by moving to
LLVM's implementation at all. If we have our own implementation, we could
in theory log at various stages of the mmaping process, but by moving to a
lib
Lgtm
On Tue, Feb 28, 2017 at 3:08 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath updated this revision to Diff 9.
> labath added a comment.
>
> rebase on top of tree
>
>
> https://reviews.llvm.org/D30402
>
> Files:
> include/lldb/Core/Debugger.h
> include/lldb/
Author: zturner
Date: Tue Feb 28 11:59:59 2017
New Revision: 296495
URL: http://llvm.org/viewvc/llvm-project?rev=296495&view=rev
Log:
Fix incorrect logic in StackFrame::Disassemble.
This had broken as the result of some previous cleanup.
Modified:
lldb/trunk/source/Target/StackFrame.cpp
Mod
s
for disassembler)
On Tue, Feb 28, 2017 at 10:13 AM Jim Ingham wrote:
> No test case?
>
> Jim
>
> > On Feb 28, 2017, at 9:59 AM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > Author: zturner
> > Date: Tue Feb 28 11:59:
Author: zturner
Date: Tue Feb 28 14:29:20 2017
New Revision: 296516
URL: http://llvm.org/viewvc/llvm-project?rev=296516&view=rev
Log:
Wrap the call to UndecorateSymbolName in a mutex.
MSDN documents that this function is not thread-safe, so we
wrap it in a global mutex.
Modified:
lldb/trunk/
Author: zturner
Date: Tue Feb 28 14:30:31 2017
New Revision: 296517
URL: http://llvm.org/viewvc/llvm-project?rev=296517&view=rev
Log:
clang-format the Mangled changes.
Modified:
lldb/trunk/source/Core/Mangled.cpp
Modified: lldb/trunk/source/Core/Mangled.cpp
URL:
http://llvm.org/viewvc/llvm-
On Tue, Feb 28, 2017 at 3:07 PM Jason Molenda wrote:
> At it's core, lldb is a real world tool that thousands of people depend
> on; breaking it or introducing bugs for little gain beyond aesthetics is a
> very poor tradeoff.
>
Just for the record, I disagree with this assertion that there is li
That patch was not really about early returns, it was about using
StringRef. So my comment about the aesthetics was referring to the patch
in general. The early return was more of a drive by, since I was already
touching the code. In that respect I was just following the well
documented and wide
On Tue, Feb 28, 2017 at 3:49 PM Jim Ingham wrote:
>
> > On Feb 28, 2017, at 3:36 PM, Zachary Turner wrote:
> >
> > That patch was not really about early returns, it was about using
> StringRef. So my comment about the aesthetics was referring to the patch
> in general. The early return was mor
On Tue, Feb 28, 2017 at 4:09 PM Jason Molenda wrote:
>
> You mentioned that this kind of mechanical churn of the code is something
> everyone else in the LLVM/LLDB community supports. I don't know about the
> LLVM community, but I strongly argue that this is the wrong way to develop
> a stable,
Author: zturner
Date: Wed Mar 1 18:05:25 2017
New Revision: 296717
URL: http://llvm.org/viewvc/llvm-project?rev=296717&view=rev
Log:
Fix various warnings. NFC
Modified:
lldb/trunk/source/Commands/CommandObjectFrame.cpp
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/sour
lgtm
On Wed, Mar 1, 2017 at 4:26 PM Jason Majors via Phabricator via
lldb-commits wrote:
> jmajors created this revision.
>
> It does not change members or call non-const members.
> HostInfo::GetArchitecture() returns a const object ref (maybe others?),
> which can't access the non-const functio
Clang-cl
On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath wrote:
>
> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> -DumpValueObjectOptions::DeclPrintingHelper helper =
> -[&valobj_
What capture does it say is missing? Also what version of msvc?
On Thu, Mar 2, 2017 at 7:17 AM Zachary Turner wrote:
> Clang-cl
> On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath wrote:
>
>
> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits <
> lldb-commits@
ing to you:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
>
>
>
> On 2 March 2017 at 15:18, Zachary Turner wrote:
> > What capture does it say is missing? Also what version of msvc?
> >
> > On Thu, Mar 2, 2017 at 7:17
Nice list, thanks!
On Thu, Mar 2, 2017 at 1:51 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jingham
> Date: Thu Mar 2 15:39:27 2017
> New Revision: 296814
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296814&view=rev
> Log:
> Added a list of outstanding proje
Tbh I felt dirty calling it Ex, so thanks for calling me out on it :)
I'll whip up some changes later
On Thu, Mar 2, 2017 at 6:09 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> Is it horrible of me to ask that we choose a name that is more descript
I was actually thinking of making the dump functions free functions that
take a const DataExtractor&. This way the entire implementation could
remain unchanged with the exception of replacing implicit member variable
reads with reads through an explicit instance of the extractor.
This way we don't
Author: zturner
Date: Fri Mar 3 00:14:38 2017
New Revision: 296855
URL: http://llvm.org/viewvc/llvm-project?rev=296855&view=rev
Log:
Remove some dead code in FileSpec.
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h
It works because we already require GnuWin32 (even just to run make at all)
On Fri, Mar 3, 2017 at 6:02 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL296869: testsuite/android: build test ex
Yea, I can see splitting the target specific stuff into a separate "target
aware" dump function and having the base one not require the exeuction
context and go in Utility. In the interest of not breaking anything it
seems reasonable to try to do that as a separate patch so we the functional
and n
Author: zturner
Date: Fri Mar 3 14:21:59 2017
New Revision: 296906
URL: http://llvm.org/viewvc/llvm-project?rev=296906&view=rev
Log:
[Windows] Remove the #include hack.
Prior to MSVC 2015 we had to manually include this header any
time we were going to include or due to a
bug in MSVC's STL im
Author: zturner
Date: Fri Mar 3 16:40:46 2017
New Revision: 296920
URL: http://llvm.org/viewvc/llvm-project?rev=296920&view=rev
Log:
Add a script to dump out all project inter-dependencies.
Added:
lldb/trunk/scripts/analyze-project-deps.py
Added: lldb/trunk/scripts/analyze-project-deps.py
U
Thanks Tim!
I have a few more file moves coming up as well, sorry for the trouble!
On Fri, Mar 3, 2017 at 3:29 PM Tim Hammerquist via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: penryu
> Date: Fri Mar 3 17:17:29 2017
> New Revision: 296925
>
> URL: http://llvm.org/viewvc/llvm-p
I can fix that, I didn't see it in my tests because it doesn't compile that
file on Windows. I'll get a fix in shortly.
On Fri, Mar 3, 2017 at 3:38 PM Tim Hammerquist
wrote:
> Sure, Zachary. I try to step in when I can.
>
> Now that you mention it, your r296910 (DumpDataExtractor) patch is
> br
:46 PM Jim Ingham wrote:
> Yeah, looks like you need to keep DumpHexBytes in DumpDataExtractor.
> That's a little weird because it doesn't actually take a DataExtractor,
> but...
>
> Jim
>
> > On Mar 3, 2017, at 3:45 PM, Zachary Turner via lldb-commits <
> lld
Author: zturner
Date: Fri Mar 3 17:52:09 2017
New Revision: 296930
URL: http://llvm.org/viewvc/llvm-project?rev=296930&view=rev
Log:
Fix DataExtractor failures.
Some code that doesn't get compiled on Windows had some references
that needed updating, and I missed those.
Modified:
lldb/trunk/
27;s a little weird because it doesn't actually take a DataExtractor,
> but...
>
> Jim
>
> > On Mar 3, 2017, at 3:45 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > I can fix that, I didn't see it in my tests because i
using any methods of DataExtractor. Oops!
> Anyway since this is no less weird than before I'll leave it this way for
> now until we figure out something better.
> >>
> >> On Fri, Mar 3, 2017 at 3:46 PM Jim Ingham wrote:
> >> Yeah, looks like you need to kee
Author: zturner
Date: Fri Mar 3 19:28:55 2017
New Revision: 296941
URL: http://llvm.org/viewvc/llvm-project?rev=296941&view=rev
Log:
Move UUID from Core -> Utility.
Added:
lldb/trunk/include/lldb/Utility/UUID.h
lldb/trunk/source/Utility/UUID.cpp
Removed:
lldb/trunk/include/lldb/Core/
Author: zturner
Date: Fri Mar 3 19:30:38 2017
New Revision: 296944
URL: http://llvm.org/viewvc/llvm-project?rev=296944&view=rev
Log:
Add dependency on DynamicLoaderStatic to Utility.
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Static/CMakeLists.txt
Modified: lldb/trunk/source/Plugins/
Author: zturner
Date: Fri Mar 3 19:31:06 2017
New Revision: 296946
URL: http://llvm.org/viewvc/llvm-project?rev=296946&view=rev
Log:
Delete LLDB's code for getting / setting thread name.
This is now functionality in LLVM, and all callers have
already been updated to use the LLVM functions.
Remo
Author: zturner
Date: Fri Mar 3 19:31:29 2017
New Revision: 296947
URL: http://llvm.org/viewvc/llvm-project?rev=296947&view=rev
Log:
Fix a bug in the dep analysis script.
It wasn't always normalizing slashes correctly, so you'd end
up with the same thing in the map twice.
Modified:
lldb/tru
the more specific part. Was that just an
> oversight?
>
> Jim
>
> > On Mar 3, 2017, at 5:31 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > Author: zturner
> > Date: Fri Mar 3 19:31:06 2017
> > New Revision: 296946
to have lost the code that would make sure that on
> platforms with short thread names we pick up the end of the name passed in
> because that is generally the more specific part. Was that just an
> oversight?
>
> Jim
>
> > On Mar 3, 2017, at 5:31 PM, Zachary Turner via lld
Author: zturner
Date: Sat Mar 4 10:42:25 2017
New Revision: 296972
URL: http://llvm.org/viewvc/llvm-project?rev=296972&view=rev
Log:
Truncate thread names if they're too long.
Modified:
lldb/trunk/source/Target/Process.cpp
Modified: lldb/trunk/source/Target/Process.cpp
URL:
http://llvm.org
I put the using only if I have to type the namespace more than once. I can
change the global using to be local, but I don't think it makes sense to
either always put the using or never put it
On Mon, Mar 6, 2017 at 3:59 AM Tamas Berghammer via Phabricator <
revi...@reviews.llvm.org> wrote:
> tberg
Weird, I could have sworn I fixed this. But looking at my disk, it's
sitting uncommitted :-/
On Mon, Mar 6, 2017 at 7:29 AM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: labath
> Date: Mon Mar 6 09:17:36 2017
> New Revision: 297013
>
> URL: http://llvm.org/viewvc
Author: zturner
Date: Mon Mar 6 11:40:36 2017
New Revision: 297035
URL: http://llvm.org/viewvc/llvm-project?rev=297035&view=rev
Log:
Fix line endings of deps analysis script.
Modified:
lldb/trunk/scripts/analyze-project-deps.py
Modified: lldb/trunk/scripts/analyze-project-deps.py
URL:
http
Author: zturner
Date: Mon Mar 6 11:41:00 2017
New Revision: 297036
URL: http://llvm.org/viewvc/llvm-project?rev=297036&view=rev
Log:
A few improvements to deps analysis scripts.
1) Looks in Plugins and clang
2) Adds a mode to display the deps sorted by the number of times
the deps occurs in a
Author: zturner
Date: Mon Mar 6 17:42:44 2017
New Revision: 297096
URL: http://llvm.org/viewvc/llvm-project?rev=297096&view=rev
Log:
Remove dependency from FileSpec to ArchSpec.
All it really needs is the llvm::Triple, so make FileSpec take
the Triple directly instead of the ArchSpec.
Modified:
Author: zturner
Date: Mon Mar 6 17:42:14 2017
New Revision: 297095
URL: http://llvm.org/viewvc/llvm-project?rev=297095&view=rev
Log:
Remove FileSpec::ReadFileContents.
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet
Author: zturner
Date: Mon Mar 6 17:52:57 2017
New Revision: 297102
URL: http://llvm.org/viewvc/llvm-project?rev=297102&view=rev
Log:
Add missing include in FileSpec.
Modified:
lldb/trunk/source/Host/common/FileSpec.cpp
Modified: lldb/trunk/source/Host/common/FileSpec.cpp
URL:
http://llvm.o
Author: zturner
Date: Mon Mar 6 21:43:17 2017
New Revision: 297116
URL: http://llvm.org/viewvc/llvm-project?rev=297116&view=rev
Log:
Use LLVM for all stat-related functionality.
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
Author: zturner
Date: Mon Mar 6 21:58:59 2017
New Revision: 297117
URL: http://llvm.org/viewvc/llvm-project?rev=297117&view=rev
Log:
Fix linux build.
Modified:
lldb/trunk/source/Host/common/FileSpec.cpp
Modified: lldb/trunk/source/Host/common/FileSpec.cpp
URL:
http://llvm.org/viewvc/llvm-p
Author: zturner
Date: Mon Mar 6 22:58:06 2017
New Revision: 297119
URL: http://llvm.org/viewvc/llvm-project?rev=297119&view=rev
Log:
Remove FileSpec dependency on FileSystem.
Modified:
lldb/trunk/source/Host/common/FileSpec.cpp
Modified: lldb/trunk/source/Host/common/FileSpec.cpp
URL:
http
Author: zturner
Date: Mon Mar 6 22:58:53 2017
New Revision: 297120
URL: http://llvm.org/viewvc/llvm-project?rev=297120&view=rev
Log:
Fix FreeBSD build.
Modified:
lldb/trunk/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
Modified: lldb/trunk/source/Plugins/Process/FreeBSD/ProcessFreeBSD.c
I think i can address this by adding a bool to llvm::sys::fs::status which
indicates whether to follow symlinks
On Tue, Mar 7, 2017 at 5:41 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> Zachary, unfortunately I had to revert this -- while investig
=
Issue Details
=
UNEXPECTED SUCCESS: test_and_run_command_dwarf
(lang/c/register_variables/TestRegisterVariables.py)
UNEXPECTED SUCCESS: test_and_run_command_dwo
(lang/c/register_variables/TestRegisterVariables.py)
UNEXPECTED SUCCESS: test_dwarf
(functionalities/thread/exit
I can run build TargetTests though (I guess it doesn't depend on editline),
and that one passes.
On Tue, Mar 7, 2017 at 2:26 PM Zachary Turner wrote:
> =
> Issue Details
> =
> UNEXPECTED SUCCESS: test_and_run_command_dwarf
> (lang/c/register_variables/TestRegisterVariable
Yes it was a debug build
On Wed, Mar 8, 2017 at 2:45 AM Pavel Labath wrote:
> I've tried it out not and it works -- I think it's good to go then.
>
> The unit tests, was that a debug build by any chance? I think we are
> missing some dependency there which shows up only on debug builds, but
> I h
Author: zturner
Date: Wed Mar 8 11:56:08 2017
New Revision: 297300
URL: http://llvm.org/viewvc/llvm-project?rev=297300&view=rev
Log:
Resubmit FileSystem changes.
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and
Author: zturner
Date: Wed Mar 8 23:12:36 2017
New Revision: 297360
URL: http://llvm.org/viewvc/llvm-project?rev=297360&view=rev
Log:
Remove LLDB's recursive directory deletion function.
LLVM now has such a function, so we use that instead.
Modified:
lldb/trunk/include/lldb/Host/FileSystem.h
Author: zturner
Date: Thu Mar 9 13:54:23 2017
New Revision: 297405
URL: http://llvm.org/viewvc/llvm-project?rev=297405&view=rev
Log:
Make the LLDB test suite work with MSVC 2017 on Windows.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
Modified: lldb/trunk/packages
You're right, I didn't notice that. But since you mention it, surely that
had to have been a bug in the original implementation right? That flag
isn't intended to be a synonym for "non recursive iteration ", because
that's what the Next enumeration value is for. The algorithm would
intentionally le
701 - 800 of 2276 matches
Mail list logo
