Re: [lldb-dev] LLDB Evolution: Next Phase

On 3 September 2016 at 00:30, Kate Stone via lldb-dev wrote: > As a reminder, any pending commits you might have planned for LLDB this > weekend must not break any of the bots we’re using to validate the health of > the source tree. Given the current non-functional state of the bots, what is the

Re: [lldb-dev] LLDB Evolution: Next Phase

Hi Ed, which bots are you referring to? Our bots were red overnight, but we've been cleaning them up now, and they should get green shortly. As far as we're concerned, the reformat can go on as planned. pl On 6 September 2016 at 13:06, Ed Maste via lldb-dev wrote: > On 3 September 2016 at 00:30

Re: [lldb-dev] LLDB Evolution: Next Phase

On 6 September 2016 at 08:51, Pavel Labath wrote: > Hi Ed, > > which bots are you referring to? Our bots were red overnight, but > we've been cleaning them up now, and they should get green shortly. As > far as we're concerned, the reformat can go on as planned. The "Buildbot General Failure - Pr

Re: [lldb-dev] LLDB Evolution: Next Phase

Wow, I had no idea things were that bad. LLDB buildbots do not seem to be affected though, so I think we should proceed. pl On 6 September 2016 at 14:09, Ed Maste wrote: > On 6 September 2016 at 08:51, Pavel Labath wrote: >> Hi Ed, >> >> which bots are you referring to? Our bots were red over

Re: [lldb-dev] LLDB Evolution: Next Phase

Yea it's only clang bots i think On Tue, Sep 6, 2016 at 6:30 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Wow, I had no idea things were that bad. LLDB buildbots do not seem to > be affected though, so I think we should proceed. > > pl > > > > On 6 September 2016 at 14:09, Ed M

Re: [lldb-dev] [Release-testers] [3.9 Release] 'final' has been tagged

Thanks! I've added the binaries to the web site now. Cheers, Hans On Sun, Sep 4, 2016 at 5:41 AM, Vasileios Kalintiris wrote: > I uploaded the binaries for MIPS, MIPSEL and the X86_64 debian8 build: > > 0e76e4cb45aaa0ee06076da43bbb27f6624abf14 > clang+llvm-3.9.0-mipsel-linux-gnu.tar.xz > 5a784

[lldb-dev] [Bug 30295] New: test infra: consider storing and re-using test inferior build artifacts for a given test directory

https://llvm.org/bugs/show_bug.cgi?id=30295 Bug ID: 30295 Summary: test infra: consider storing and re-using test inferior build artifacts for a given test directory Product: lldb Version: unspecified Hardware: PC

Re: [lldb-dev] LLDB Evolution: Next Phase

This has been in the works long enough to get plans together. If the current state of a bot suggests that manual validation is required then that’s what I’d recommend. That’s the unfortunate current state of affairs with the Green Dragon bots, for example. Kate Stone k8st...@apple.com

[lldb-dev] LLDB REFORMATTING IN PROGRESS

As has been discussed over the past few weeks the reformatting of the LLDB code base will take place shortly, followed by validation before committing these changes. Please suspend all commit activity. Any intervening commits will be reverted until the all-clear is given. Kate Stone k8st...@a

[lldb-dev] [Bug 30299] TestDarwinLogFilterRegexMessage tests sometimes fail

https://llvm.org/bugs/show_bug.cgi?id=30299 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- You are receiving this ma

[lldb-dev] [Bug 30299] New: TestDarwinLogFilterRegexMessage tests sometimes fail

https://llvm.org/bugs/show_bug.cgi?id=30299 Bug ID: 30299 Summary: TestDarwinLogFilterRegexMessage tests sometimes fail Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: nor

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

The storm of commit messages might be a subtle clue, but here it is officially: the reformatting is complete and I’ve verified that no tests regressed locally in our macOS suite. Please begin any validation process you’ve signed up for on another platform, and if changes are necessary go ahead

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

I think it goes without saying, but henceforth, no changes should be landed without first passing them through clang-format. Personally, I will be reverting any I see that don't conform. But I can't promise to catch all of them. On Tue, Sep 6, 2016 at 2:17 PM Kate Stone via lldb-dev < lldb-dev@l

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

On 6 September 2016 at 17:17, Kate Stone via lldb-dev wrote: > The storm of commit messages might be a subtle clue, but here it is > officially: the reformatting is complete and I’ve verified that no tests > regressed locally in our macOS suite. Please begin any validation process > you’ve signed

[lldb-dev] All clear on FreeBSD after reformatting

On 6 September 2016 at 17:26, Ed Maste wrote: > > FreeBSD currently fails to build due to header reordering in > source/Host/freebsd/Host.cpp which I'll sort out shortly. > > I'd like to request that we avoid any functional changes other than > those restoring builds to green, until we get the "al

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

Everything compiles on Windows now but all the tests are failing with ERROR. I'm looking into this now. On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 6 September 2016 at 17:17, Kate Stone via lldb-dev > wrote: > > The storm of commit messages might

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

I think Windows is good. On Tue, Sep 6, 2016 at 3:10 PM Zachary Turner wrote: > Everything compiles on Windows now but all the tests are failing with > ERROR. I'm looking into this now. > > On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > On 6 Septemb

[lldb-dev] Running Clang-format automatically in CMake

Hi! Since LLDB code is freshly formatted, it may make sense to run Clang-format automatically via CMake. If not as part of regular build, but may be subtarget of install or check targets as it done in Polly. Eugene. ___ lldb-dev mailing list lldb-dev@li

Re: [lldb-dev] Running Clang-format automatically in CMake

What would be the gain of such a thing? It would be extremely slow to run clang-format every single time you ran CMake, and also having a run of CMake generate changes to your source tree seems like using the wrong tool for the job. I think we should follow whatever LLVM does, which in this case